Bolt est-il sûr ? Ce que 1 123 applications Bolt ont montré

Vous avez construit quelque chose sur Bolt, appuyé sur Publish, et l’application vit maintenant à une adresse qui se termine par bolt.host. Avant d’envoyer ce lien à de vrais clients, vous avez tapé « bolt est-il sûr » dans un champ de recherche, et ce qui est revenu était une liste de cinq vulnérabilités présentes, disait-on, dans presque toutes les applications Bolt, avec un scanner à vendre en bas de page.

Voici où ces listes se trompent : elles mettent tous les risques au même niveau, et sur les applications Bolt en ligne la plupart apparaissent à peine. Source maps, en-têtes cross-origin ouverts et routes d’API non protégées y figurent à égalité avec les clés qui fuient et les tables ouvertes. Dans nos données, les trois premiers sont apparus sur 13, 1 et 4 applications sur plus de mille. Les deux autres sont là où se trouvaient les trouvailles.

Entre le 12 et le 14 août 2026, nous avons passé les mêmes neuf vérifications externes, que n’importe qui peut lancer gratuitement depuis notre page d’accueil, sur 30 998 applications en ligne, et 1 123 d’entre elles étaient publiées sur l’hébergement de Bolt. Voici ce qui est revenu pour celles-là, et où s’arrête notre regard.

Bolt est-il sûr ?

Pour tout ce que Bolt décide lui-même, oui. Son hébergement est ressorti aussi propre que celui de Lovable, et tout ce qui a fait baisser une note se trouvait dans une application construite par son propriétaire.

Imaginez une application Bolt comme une boutique. Bolt construit le bâtiment : l’adresse, le certificat, l’hébergement. Vous remplissez la vitrine, c’est-à-dire chaque page, chaque image et chaque script que votre application remet à un visiteur, et quiconque passe devant peut lire ce qu’il y a dedans. Derrière la boutique se trouve la réserve, votre base de données, avec sa propre porte et sa propre serrure. « Bolt est-il sûr » recouvre en fait trois questions, une pour chacun.

1. Le bâtiment. Bolt publie-t-il correctement votre application : un certificat valide, un domaine qui n’expirera pas, rien d’égaré à une adresse publique. C’est le travail de Bolt.
2. La vitrine. Ce que le navigateur d’un visiteur télécharge. Une clé laissée dedans peut être lue par quiconque regarde, peu importe comment elle y est arrivée.
3. La réserve. Votre base de données répond-elle à un inconnu qui fait le tour par l’arrière et demande ? Cela dépend d’une serrure que vous posez, table par table.

Nos vérifications lisent les trois depuis l’extérieur. Aucune ne lit le code qu’a écrit l’agent de Bolt comme vous le liriez dans l’éditeur, et cet article ne devine pas à sa place.

Ce que nous avons trouvé dans 1 123 applications Bolt

Neuf vérifications, lancées depuis l’extérieur, sans connexion et sans accès au compte de qui que ce soit. Quand une base de données répondait, nous lui avons demandé combien de lignes elle remettrait et nous nous sommes arrêtés là ; nous n’en avons lu aucune. Aucune application n’est nommée ici ni ailleurs dans ce que nous publions. Chaque proportion ci-dessous porte sur les applications où la vérification a répondu, car une vérification qui n’a pas pu aboutir est inconnue, pas réussie, et c’est pour cela que les dénominateurs bougent. La méthode et les données sont dans le rapport.

Les notes : 1 051 A, 33 B, 24 C, 15 D et aucun F.

Cette première ligne dépend de ce qui sert vos pages, et sur yourapp.bolt.host c’est Bolt, donc 1 121 applications ont reçu la même réponse. Les en-têtes valent la peine, et ce n’est pas avec eux qu’on fait un D. Retirez cette ligne et 1 008 des 1 123 applications Bolt n’avaient rien d’autre du tout. Les 115 restantes font le sujet de la suite de cet article.

Ce que Bolt fait bien

Les vérifications qui dépendent de Bolt sont revenues presque vides, et sur le seul réglage de build que nous mesurons, Bolt fait jeu égal avec Lovable.

Source maps. 13 applications Bolt sur 1 123 publient les fichiers d’origine derrière l’application, commentaires compris. C’est un peu plus d’une sur cent, à peu près le même taux que les 225 sur 18 553 de Lovable, et une map en dit plus qu’on ne le croit.

En-têtes cross-origin. Une application sur 1 120 annonçait à tous les sites du monde qu’ils pouvaient appeler son API. C’est la trouvaille la plus susceptible de laisser un autre site agir à la place de votre utilisateur, et chez Bolt elle est apparue une fois.

Le bâtiment lui-même. Le certificat était valide sur les 1 119 applications où nous avons pu en lire un, aucun domaine sur 1 123 n’était près d’expirer, et aucune application ne servait un fichier .env ou un .git/config à une adresse ordinaire.

Rien de tout cela ne vous demandait quoi que ce soit, et sur certains autres builders, si.

De quoi étaient faites les 75 clés

La plupart étaient sans problème, et les rares qui ne l’étaient pas sont ce qui coûte le plus cher dans cet article.

75 des 1 123 applications Bolt avaient quelque chose qui ressemble à une clé dans le code qu’un visiteur télécharge. Comptées comme des formes, cela fait 7 % des applications Bolt qui « laissent fuiter des secrets ». Comptées selon ce que chaque clé peut faire, elles se répartissent ainsi, chaque application étant comptée une fois, sous ce qu’elle contient de plus grave :

Les 38 clés Google sont la raison pour laquelle nous classons chaque clé au lieu de simplement repérer un motif. Une clé Google Maps dans un navigateur est là où elle doit être, et la correction consiste à la limiter à votre propre domaine.

Les dix clés OpenAI sont le cas inverse. Une clé OpenAI est un jeton porteur (bearer token) : celui qui la détient peut la dépenser, depuis n’importe où, et OpenAI ne propose aucun réglage qui lie une clé à votre site. Ces dix applications ont toutes reçu un D, parce qu’une seule trouvaille critique plafonne la note, quoi que l’application ait bien fait par ailleurs. Que faire quand vous en trouvez une, dans l’ordre commence par la renouveler aujourd’hui.

Voici le chiffre qui fait de cette trouvaille celle de Bolt. Les applications Bolt représentaient moins de 4 applications scannées sur 100, et elles portaient 10 des 33 clés OpenAI que nous avons trouvées, toutes plateformes confondues. Rapporté à chaque application, cela fait environ une application Bolt sur 110, contre 18 des 18 554 applications Lovable, environ une sur mille. Dix applications, c’est un petit échantillon, et quelques-unes de plus ou de moins feraient beaucoup bouger ce rapport. Bolt resterait malgré tout devant tous les autres builders que nous avons mesurés.

Pourquoi les applications Bolt laissent-elles fuiter des clés d’API ?

De l’extérieur, nous ne voyons pas comment l’une de ces dix clés est arrivée là, et les propres instructions de Bolt disent qu’aucune n’aurait dû y être.

La documentation de Bolt décrit le chemin prévu. Demandez à l’agent d’intégrer OpenAI et, selon les termes de la documentation, il va « terminer le code puis afficher un message vous demandant d’ajouter votre secret ». Ce secret va dans le panneau Secrets, où seule une fonction serveur peut le lire. Une fonction serveur tourne du côté de Bolt, donc le navigateur du visiteur ne reçoit jamais la clé. Construite ainsi, la clé reste dans la réserve.

Le détour que nous pouvons nommer, c’est la variable d’environnement. L’introduction de Bolt aux bases de données dit que les variables d’environnement gardent ces valeurs privées, et deux des trois noms qu’elle cite, VITE_SUPABASE_URL et VITE_SUPABASE_ANON_KEY, commencent par VITE_. Ce préfixe appartient à Vite, l’outil de build, et la documentation de Vite dit l’inverse à son sujet : une variable VITE_ est écrite dans le code que le navigateur télécharge, et elle ne doit jamais contenir de clé d’API. Pour ces deux noms, c’est sans conséquence, car l’adresse d’un projet et une clé publiable sont faites pour être publiques. Reprenez le même schéma pour VITE_OPENAI_API_KEY et la clé se retrouve dans la vitrine.

Une clé collée dans le chat pendant que vous répariez autre chose peut aussi finir écrite directement dans une page. Dans les deux cas, le résultat est le même fichier. Comment fonctionne le préfixe explique quelles valeurs ont leur place derrière et lesquelles jamais.

27 sur 35 : les bases Bolt que nous avons pu interroger

Parmi les bases de données Bolt qui nous ont donné une réponse exploitable, 27 sur 35 ont remis des lignes à une requête sans aucune connexion. C’est un décompte, et la base est trop petite pour l’imprimer en pourcentage.

Les dénominateurs comptent ici plus que partout ailleurs dans cet article. 266 des 1 123 applications Bolt nommaient un projet Supabase dans le code qu’elles livrent. Seules 35 d’entre elles ont répondu assez bien pour que nous puissions juger. Les 231 autres n’ont pas pu être jugées, ce qui les rend inconnues, et nous ne les avons comptées ni comme propres ni comme exposées.

Dans 4 des 27, la table qui a répondu portait le genre de nom qu’on donne aux tables qui parlent de personnes, comme users ou profiles. Ces quatre-là et les onze applications avec une clé OpenAI ou Anthropic font à elles seules les 15 notes D. Dans les 23 autres, c’était une table que nous ne pouvions pas identifier de l’extérieur, peut-être une liste de produits faite pour être publique, peut-être tout autre chose.

Pourquoi tout se joue dans la base de données

Parce que l’adresse de la réserve est affichée dans la vitrine, et qu’elle doit l’être.

Quand une application Bolt lit ses données depuis la page, la page a besoin de l’adresse de la base et d’une clé publiable, donc les deux voyagent jusqu’à chaque visiteur. Que cette clé soit publique est normal ; c’est par là que votre propre application entre. Ce qu’elle obtient en retour dépend d’un réglage par table appelé Row Level Security. Activé, avec une policy écrite, la clé publique ne lit que les lignes que la policy autorise. Désactivé, elle lit la table.

Supabase active la Row Level Security par défaut pour les tables que vous créez à la souris dans son Table Editor. Les tables créées en exécutant du SQL ne l’ont pas, et exécuter du SQL est justement la façon dont un builder crée des tables pour vous. L’activer n’est d’ailleurs que la première étape, car la policy qu’un assistant écrit pour faire disparaître une erreur de permissions est souvent using (true), qui autorise tout le monde pendant que le tableau de bord affiche la table comme protégée. La RLS est activée et votre table est toujours publique raconte toute cette histoire.

La propre vérification de base de données de Bolt cherche exactement cela : sa documentation la décrit comme trouvant « une policy de Row Level Security (RLS) manquante ou une permission trop ouverte ». Le guide en langage simple pour cette plateforme est votre application Bolt est-elle sûre.

Ce que vérifie l’audit de sécurité de Bolt

Il lit votre projet de l’intérieur, et il tourne quand vous appuyez sur le bouton.

Bolt a annoncé l’audit le 30 juillet 2026. Sur une offre payante, il se trouve dans le menu Publish sous le nom Run security audit : il passe en revue votre code et votre base de données, corrige lui-même la plupart des problèmes, signale le reste et ne consomme pas vos tokens. Sur toutes les offres, y compris la gratuite, les réglages d’une base de données Bolt ont une section Security qui lance la vérification de Row Level Security décrite plus haut.

Notre scan a eu lieu deux semaines après l’apparition de ce bouton, donc les chiffres ci-dessus ne peuvent pas dire combien il a changé les choses depuis. Ce que nous pouvons dire, c’est comment les deux points de vue s’emboîtent. L’audit voit votre projet de l’intérieur, y compris des tables que vos pages ne mentionnent jamais, ce qu’un scan depuis l’extérieur ne peut jamais faire. Un scan depuis l’extérieur voit ce qu’un inconnu obtient de l’application publiée. Quand un audit se termine, le bouton affiche Security audit up to date, et la prochaine modification que vous publiez est une modification qu’il n’a pas vue.

Lancez l’audit avant de publier et regardez depuis l’extérieur ensuite. Si les deux ne sont pas d’accord sur le fait qu’une table soit lisible, fiez-vous à la réponse de l’extérieur, parce que c’est celle qu’obtient un inconnu.

Comment vérifier votre propre application Bolt

Cinq choses à regarder. Utilisez une fenêtre privée, pour que votre propre connexion ne réponde pas à la place d’un inconnu.

1. Sachez quelle base de données vous avez. Les nouveaux projets Bolt utilisent une base Bolt par défaut. Si vous avez choisi Supabase à la création du projet, ou en avez connecté un plus tard, vos tables vivent dans un projet Supabase auquel vous pouvez vous connecter.
2. Lisez la serrure de chaque table. Avec une base Bolt, ouvrez la section Security des réglages de la base et lancez la vérification. Avec Supabase, ouvrez Authentication → Policies et lisez la liste : une table dont la Row Level Security est désactivée est lisible par quiconque a l’adresse de votre projet, et cette adresse est dans votre application. Une policy qui autorise tout le monde compte comme désactivée.
3. Cherchez VITE_ dans votre projet. Chaque valeur derrière ce préfixe est dans la vitrine. L’adresse d’un projet et une clé publiable y ont leur place. Une clé qui vous facture a sa place dans le panneau Secrets, lue par une fonction serveur. Si l’une d’elles s’est déjà trouvée derrière le préfixe, renouvelez-la d’abord chez le fournisseur, car l’ancienne valeur continue de marcher tant que vous ne l’avez pas fait.
4. Regardez votre stockage. Un bucket marqué public liste chacun de ses fichiers à quiconque le demande, y compris ceux que votre application n’affiche jamais.
5. Ou laissez le scan s’en charger. Il fait cela depuis l’extérieur, plus cinq autres vérifications, prend environ 20 secondes, ne demande pas de compte, et vous montre une note et ce qui l’a produite : scannez votre application gratuitement.

Pour que cela reste vrai après la publication

Une vérification du mois dernier décrit l’application du mois dernier. Sur Bolt, publier tient en un bouton, donc une table ajoutée ce matin ou une clé collée à minuit est en ligne dès que vous appuyez.

Reeve Monitor relance les neuf vérifications pour vous :

• les neuf vérifications toutes les heures, sur trois applications au plus
• si l’application répond, toutes les 60 secondes
• un message quand un résultat change, pour qu’une nouvelle trouvaille n’attende pas que vous regardiez
• un rapport mensuel de ce qu’il a vu

Monitor coûte €12 par mois au tarif public, avec sept jours gratuits avant le premier prélèvement. La page des tarifs est parfois en dessous du chiffre donné ici, jamais au-dessus.

Si votre application Bolt garde ses données dans votre propre projet Supabase, Reeve Care en conserve une copie. Cela vaut pour un projet connecté dès le départ comme pour une base Bolt que vous avez récupérée dans Supabase.

• une copie chiffrée de votre base Supabase chaque nuit, gardée là où votre projet ne peut pas l’atteindre
• chaque copie vérifiée avant de compter, en dénombrant les lignes de chaque table
• une restauration en un clic quand vous en avez besoin
• vos fichiers téléversés aussi, dès que vous connectez un accès Storage
• tout ce que fait Monitor

Care coûte €49 par mois au tarif public pour une application, avec les mêmes sept jours gratuits.

Une table ouverte, c’est quelque chose qu’un inconnu peut lire. Une migration partie dans le mauvais sens, ou un agent ayant accès à la base, c’est quelque chose qui peut la vider, et aucune des neuf vérifications de cet article ne ramènerait les lignes. Le jour où un agent IA a supprimé une base de production montre à quoi cela ressemble de l’intérieur.

Que faire cette semaine

Commencez par la recherche de VITE_, car c’est la seule trouvaille sur Bolt qui coûte de l’argent à elle seule. Si vous hésitez encore entre plusieurs builders, quel builder d’applications IA est le plus sûr met les cinq côte à côte.