Sécuriser une app Bolt (bolt.new) avant de la déployer

Bolt te sort une app qui tourne en quelques prompts, et te propose de la déployer sur Netlify en un clic. C'est fluide. Le piège, c'est que Bolt construit avec Vite, et Vite a une règle que peu de gens connaissent : tout ce que tu ranges dans une variable préfixée VITE_ part dans le bundle JavaScript, donc dans le navigateur de chaque visiteur.

Résultat : une clé que tu croyais planquée dans un .env se retrouve en clair sur ton app en ligne. Sur les apps que je scanne, les deux failles qui reviennent le plus sont la même partout : une clé secrète exposée et une base Supabase lisible. Voilà comment ça arrive sur Bolt, et comment le vérifier avant de déployer.

Ce que Bolt expose que tu ne vois pas

Quand tu bosses dans Bolt, tout tourne dans le navigateur, dans un environnement isolé (les WebContainers). Ça marche, tu vois ton app, tout va bien. Le moment qui compte, c'est le déploiement : Bolt pousse ton app buildée sur Netlify, et à partir de là, le monde entier peut télécharger ce bundle et le lire.

Ce bundle contient tout le code du front, et toutes les variables d'environnement préfixées VITE_. C'est voulu côté Vite, ces variables sont là pour être utilisées par le navigateur. Le problème, c'est quand tu (ou l'IA) y ranges une clé qui n'aurait jamais dû sortir du serveur.

Le piège du préfixe VITE_

Voilà la règle à retenir. Dans une app Vite, VITE_MA_CLE est envoyée au navigateur. MA_CLE sans le préfixe reste côté serveur au build et n'est pas exposée. Sauf qu'une app Bolt purement front n'a pas de « côté serveur » à l'exécution : tout ce dont l'app a besoin pour tourner doit être accessible au navigateur, donc préfixé VITE_.

C'est là que ça dérape. La clé anon de Supabase en VITE_SUPABASE_ANON_KEY, c'est normal, elle est publique. Mais si l'IA range aussi une VITE_SUPABASE_SERVICE_ROLE_KEY ou une clé d'API payante avec le préfixe, pour que « l'appel marche depuis le front », tu viens de publier ta clé secrète. Elle est dans le fichier .js que n'importe qui ouvre.

Comment vérifier : ouvre ton app Bolt déployée, clic droit, Inspecter, onglet Sources, et cherche service_role, sk_live, sk-, ou le nom de tes clés d'API. Si tu tombes dessus, régénère la clé côté fournisseur (elle est grillée), et déplace l'appel qui l'utilise dans une fonction serveur (une Netlify Function ou une Edge Function Supabase), jamais dans le front.

Ta base Supabase, le même verrou à vérifier

Beaucoup d'apps Bolt branchent Supabase pour stocker les données. Et comme partout, ce n'est pas la clé publique qui protège ta base, c'est le RLS (Row Level Security). Tant qu'il est désactivé sur une table, la clé anon visible dans ton app suffit à lire toutes les lignes.

Le geste manquant, c'est toujours le même : activer le RLS et poser une règle qui dit qui a le droit de lire quoi. L'IA branche la base, elle ne verrouille pas derrière. Je détaille la faille et les règles à coller dans RLS désactivé : pourquoi ta base est lisible, et tu peux le vérifier toi-même en deux minutes avec les DevTools.

Côté Colmate, on ne va jamais lire ta base pour te le prouver. On repère que ton app utilise Supabase avec une clé publique exposée côté client, et on te signale l'exposition probable à vérifier. On déduit à partir du public, on ne fouille pas.

Les en-têtes de sécurité sur Netlify

Comme ton app Bolt finit sur Netlify, c'est là que se posent les en-têtes de sécurité (CSP, HSTS, X-Frame-Options). Bolt ne les ajoute pas pour toi. Ces en-têtes sont les serrures secondaires : seuls, ils ne fuient pas de données, mais leur absence ouvre la porte au détournement de session et à l'injection de code. Ils comptent aussi dans les mesures techniques demandées par le RGPD (article 32).

Comment vérifier : dans l'onglet Réseau des DevTools, clique sur la première requête (le document HTML) et regarde les Response Headers. Si Content-Security-Policy et Strict-Transport-Security manquent, tu peux les ajouter côté Netlify avec un fichier _headers ou netlify.toml, sans toucher au code de ton app.

Combien d'apps sont réellement concernées ?

Sur une dizaine d'apps que je scanne un matin au hasard des pubs, 8 sur 10 exposent quelque chose. Une clé secrète en clair, du code source accessible, des en-têtes absents. Deux seulement étaient propres. La vitesse des builders comme Bolt est réelle, et le revers aussi : on déploie avant d'avoir fermé quoi que ce soit.

Ça ne veut pas dire que Bolt est mauvais. Ça veut dire qu'après le déploiement, il reste une étape que l'outil ne fait pas à ta place. La même que pour Lovable, v0 et Replit.

La version rapide

Colmate passe cette revue en trente secondes depuis l'URL de ton app Bolt déployée. Tu colles le lien, tu obtiens la liste de ce qui est exposé (clés, source maps, en-têtes), classé par gravité, avec le correctif prêt à coller dans ton IA. Pour la base, il repère la présence de Supabase avec une clé publique exposée et te signale l'exposition à vérifier, sans y toucher. En lecture seule, sans accès à ton code.

Scanne ton app Bolt avant de la lancer. Tu sauras tout de suite ce qui fuit et ce qui reste à vérifier.

FAQ

Une variable VITE_ est-elle toujours visible dans le navigateur ?

Oui. Tout ce qui est préfixé VITE_ est injecté dans le bundle au build et téléchargé par chaque visiteur. C'est fait pour, ces variables servent au front. La règle est simple : ne mets jamais une clé secrète derrière un préfixe VITE_. Une clé secrète doit rester dans une fonction serveur, jamais dans une variable exposée au navigateur.

Netlify sécurise-t-il mon app Bolt automatiquement ?

Netlify te donne le HTTPS et l'hébergement, mais il ne verrouille pas ta base Supabase, ne cache pas tes clés et ne pose pas de CSP à ta place. Les en-têtes de sécurité s'ajoutent avec un fichier _headers ou netlify.toml. Le reste (RLS, secrets côté serveur) dépend de ton app, pas de l'hébergeur.

J'ai trouvé une clé exposée dans mon app Bolt, je fais quoi ?

Deux gestes, dans cet ordre. D'abord tu régénères la clé chez son fournisseur : celle qui est exposée est à considérer comme compromise, même si personne ne l'a encore utilisée. Ensuite tu déplaces l'appel qui s'en sert vers une fonction serveur, pour que la nouvelle clé ne repasse jamais par le navigateur.

Le réflexe avant de déployer

Avant de pousser ton app Bolt sur Netlify, ouvre-la comme le ferait un visiteur et regarde ce qu'elle sert vraiment. C'est le geste le plus rentable avant un lancement. Passe la checklist complète en un scan, ou repars de la checklist avant déploiement pour la faire à la main.