Reeve Votre appli Bolt est-elle sûre ?
Bolt est-il sûr pour construire ? Le code est rarement en cause. Ce qui décide, c'est si les tables que Bolt a écrites pour vous ont été verrouillées.
Les logos sont la propriété de leurs détenteurs respectifs et servent uniquement à indiquer la compatibilité.
En bref
- Une appli Bolt est en général sûre côté code. Ce qui décide, c'est si les tables que Bolt a générées ont un jour été verrouillées.
- Les tables créées en exécutant du SQL ne reçoivent pas Row Level Security par défaut, et écrire du SQL est la façon dont Bolt les crée.
- Une clé publiable dans votre appli est correcte. sb_secret_… ou service_role qui atteint le navigateur, c'est celle à renouveler aujourd'hui.
Bolt écrit tout le projet : les écrans, le câblage, et les tables de base de données en dessous. Cette dernière partie est celle que vous ne voyez jamais, et c'est là que commence en réalité presque toute histoire de « mon appli Bolt fuit des données ».
Voici ce que guide après guide raconte de travers : le code écrit par Bolt est rarement le problème. Le problème est en général un seul interrupteur, table par table, dans votre base, qui n'a jamais été allumé, à cause de la façon dont les tables ont été créées, et non parce que quelqu'un a fait une erreur.
Ce que Bolt remet à un visiteur, et ce qu'il garde
Deux moitiés, et une seule est privée.
Voyez cela comme une boutique. Bolt vous construit une devanture (pages, boutons, formulaires), et cette devanture est remise en entier à chaque visiteur qui charge votre site. Il le faut bien. Un navigateur ne peut pas afficher une page qu'on ne lui a pas donnée, donc il n'existe aucune version où la façade de votre appli reste secrète. Derrière se trouve une réserve, votre base Supabase, un bâtiment séparé avec sa propre serrure.
L'hypothèse qui coûte cher est que la devanture commande la réserve. Elle ne la commande pas. Votre base est sur internet avec sa propre adresse, et cette adresse est imprimée sur la devanture parce que c'est ainsi que votre appli l'atteint. Quiconque lit vos fichiers publiés lit l'adresse aussi, et peut alors parler à la réserve sans jamais traverser votre boutique.
Est-ce un problème que mon appli Bolt contienne une clé API ?
En général non. Tout dépend de laquelle, et il y en a deux qui se ressemblent presque trait pour trait.
Une clé publiable nomme votre projet et rien d'autre. Supabase l'appelle
sb_publishable_… dans les projets récents et anon dans les anciens, et elle
est faite pour vivre dans un navigateur où n'importe qui peut la lire. Une clé
secrète (sb_secret_…, ou service_role avant le renommage) est
l'inverse. Elle ignore toutes les règles que vous avez écrites et lit et écrit
chaque ligne de chaque table.
Elles sont côte à côte dans le tableau de bord Supabase, font à peu près la même longueur, et se comportent pareil pendant que vous construisez. Rien ne casse si la mauvaise est copiée, et c'est précisément pour cela qu'elle survit jusqu'en production. La version longue de comment les distinguer se lit en une minute.
L'interrupteur qui décide à qui votre base répond
Row Level Security est un réglage par table dans Supabase qui décide, ligne par ligne, qui peut lire quoi. Éteint, votre clé publiable renvoie la table entière. Allumé, avec une politique écrite, elle ne renvoie que les lignes que cette politique autorise.
Vient maintenant la partie qui s'applique à un projet Bolt en particulier. Supabase active Row Level Security par défaut pour les tables créées dans le Table Editor du tableau de bord, celui où l'on clique. Les tables créées en exécutant du SQL ne l'obtiennent pas et doivent être activées délibérément.
Bolt crée vos tables en écrivant du SQL.
La forme habituelle d'un projet Bolt est donc un ensemble de tables générées arrivées déverrouillées, à côté de ce que vous avez ajouté à la main ensuite, qui ne l'était pas. Les deux sont indiscernables dans l'éditeur et marchent parfaitement toutes les deux. Et activer le réglage n'est pas non plus la ligne d'arrivée : une table avec Row Level Security activé et une politique qui autorise tout le monde est ouverte tout en se déclarant fermée.
Comment vérifier votre appli Bolt en une dizaine de minutes
Lisez votre liste de politiques. Dans Supabase, Authentication → Policies affiche chaque table avec l'état de Row Level Security. Commencez par tout ce qui est marqué désactivé ; c'est lisible par quiconque connaît l'adresse de votre projet.
Confirmez quelle clé vous avez publiée. Settings → API dans Supabase montre les deux. La clé publiable dans votre appli est correcte et ne demande rien. Si une clé secrète a un jour été collée dans le projet, renouvelez-la là avant de toucher à votre code : supprimer la ligne ne ferme pas la porte, car l'ancienne valeur survit dans les copies en cache de votre site.
Vérifiez vos buckets de stockage. Un bucket marqué public peut être listé et téléchargé par n'importe qui, que votre appli renvoie ou non vers les fichiers qu'il contient.
Puis regardez depuis l'extérieur. Tout ce qui précède vous dit ce qui est configuré. Cela ne vous dit pas ce qu'un inconnu atteint réellement, qui est une autre question et celle qui compte. Notre scan gratuit lit votre site en ligne comme le ferait n'importe quel visiteur et vous donne une note en une vingtaine de secondes, sans compte : scanner votre appli.
Que faire
- Tout ce que Bolt envoie à un navigateur est lisible par n'importe qui. C'est ainsi que fonctionnent les navigateurs, et le cacher n'est pas une piste qui vaille la peine.
- Une clé publiable dans votre appli est correcte. Une clé secrète (
sb_secret_…ouservice_role) est celle à renouveler aujourd'hui. - Les tables créées en exécutant du SQL ne reçoivent pas Row Level Security par défaut, et écrire du SQL est la façon dont Bolt crée les tables.
- Activer le réglage est la première étape. Une politique qui autorise tout le monde laisse la table ouverte pendant que le tableau de bord l'affiche comme protégée.
- Que votre appli marche ne prouve pas qu'elle est verrouillée. Vus de l'intérieur, les deux états sont identiques.
Ouvrez Authentication → Policies dans Supabase et lisez la liste de haut en bas. Si quelque chose y indique Row Level Security désactivé, c'est par cette table qu'il faut commencer, et la checklist sécurité en 10 minutes couvre le reste de la surface une fois que c'est fait.
Ce qui peut réellement mal tourner avec une appli Bolt
Rien de tout cela ne signifie que vous avez fait quelque chose de mal : ce sont les effets secondaires habituels d'une création rapide. Voici ce qui vaut la peine d'être vérifié :
Une clé secrète qui atterrit dans le navigateur (le piège VITE_)
Les applis Bolt sont généralement construites avec Vite, qui a une règle qui piège les gens : tout réglage dont le nom commence par VITE_ est intégré dans le code qui s'exécute dans le navigateur de votre visiteur, où n'importe qui peut le lire. Nommez un vrai secret VITE_QUELQUECHOSE et il part au public. Certaines clés sont censées être publiques (comme une clé « anon » de Supabase), ce qui ne pose pas de problème : Reeve distingue les sûres des dangereuses, donc pas de fausses alertes.
Votre base de données laissée ouverte (RLS de Supabase désactivé)
Bolt relie souvent votre appli à Supabase pour les données. Supabase possède un interrupteur appelé Row Level Security (RLS) qui décide qui peut lire ou modifier chaque ligne. S'il est désactivé, vos tables peuvent être lisibles, ou modifiables, par quiconque trouve l'adresse. C'est le problème sérieux le plus fréquent dans les applis créées par IA, et il est invisible tant que vous ne vérifiez pas.
Un fichier .env ou de configuration exposé
Le fichier .env contient les clés et mots de passe d'un projet. Parfois, il est publié par accident en même temps que l'appli déployée. S'il est accessible depuis l'extérieur, c'est un raccourci vers tout ce qui est sensible. Reeve vérifie si le vôtre est discrètement accessible.
Stockage de fichiers public
Si des gens téléversent des fichiers dans votre appli, ceux-ci vivent dans des « espaces » (buckets) de stockage. Un espace laissé public signifie que n'importe qui peut lister ou télécharger ce qu'il contient, et un téléversement privé peut donc finir visible par tous. Reeve vérifie si vos espaces sont listables ; il ne télécharge jamais les fichiers de qui que ce soit.
Source maps laissées actives
Une « source map » est un fichier d'aide qui révèle le code d'origine de votre appli. Pratique pendant le développement, mais si elle part en production, elle donne aux inconnus une carte lisible du fonctionnement de votre appli, rendant chaque autre porte plus facile à trouver. Faible urgence, mais bon à ranger.
En-têtes de sécurité manquants & points d'accès ouverts
De petits réglages qui indiquent aux navigateurs comment protéger vos visiteurs, plus le fait que vos points d'accès de données répondent à n'importe qui ou à n'importe quel site. Mineurs isolément ; ensemble, ils élargissent la faille. Reeve signale ceux qui manquent.
Ce que Reeve est, et ce qu'il n'est pas
Reeve est une vérification gratuite, en lecture seule, depuis l'extérieur, comme un inspecteur qui fait le tour du bâtiment et essaie les portes. C'est rapide et ça repère les erreurs courantes à fort impact. Ce n'est pas un audit de sécurité complet, et une note propre n'est pas une garantie. Elle signifie que les portes évidentes sont fermées.
Bolt et StackBlitz améliorent sans cesse ce qui est généré, et si votre appli utilise Supabase, le conseiller de Supabase signale les problèmes de base de données dans son tableau de bord. Les deux aident. Ce que Reeve ajoute : vous vivez dans Bolt, pas dans un tableau de bord, et ces outils parlent le langage des développeurs. Reeve regarde toute votre appli déployée depuis l'extérieur, comme le ferait un inconnu, et vous dit ce qu'il trouve dans des mots exploitables. Et si vous préférez ne pas y penser, nous pouvons la surveiller pour vous.
Vous voulez que ce soit géré, pas seulement vérifié ?
Reeve Care continue de surveiller votre appli, sauvegarde vos données et vous aide à réparer les choses quand elles cassent, pour que vous puissiez continuer à créer au lieu de vous inquiéter.
En savoir plus sur Reeve CareFAQ
Mon appli Bolt est-elle sûre par défaut ?
Bolt vous donne rapidement une appli qui fonctionne, mais « sûre par défaut » dépend de la façon dont elle est câblée, en particulier de vos variables d'environnement et, si vous utilisez Supabase, des règles de votre base de données. Le seul moyen de le savoir est de vérifier ce qui est réellement exposé, ce que Reeve fait gratuitement en environ 20 secondes.
Pourquoi ma clé d'API a-t-elle fuité dans une appli Bolt ?
Généralement parce qu'elle était stockée dans un réglage commençant par VITE_. Vite intègre volontairement ceux-là dans le bundle du navigateur, donc tout secret nommé ainsi devient public. Reeve lit le code chargé de votre appli, trouve les clés et vous dit lesquelles sont sûres à exposer et lesquelles doivent être déplacées vers le serveur.
Bolt utilise-t-il Supabase, et est-ce sûr ?
Bolt connecte fréquemment les applis à Supabase. Supabase est sûr quand la Row Level Security est activée et que seule votre clé publique « anon » est dans le front-end. Si le RLS est désactivé ou qu'une clé « service_role » a fuité, vos données peuvent être exposées. Reeve vérifie les deux sans jamais lire vos données réelles.
Analyser mon appli Bolt va-t-il modifier quelque chose ?
Non. Reeve regarde seulement ce qui est déjà public depuis l'extérieur. Il ne se connecte jamais, ne modifie jamais rien et ne télécharge jamais vos fichiers. En lecture seule, comme vérifier si une porte est verrouillée sans entrer.
Bolt a écrit mes tables de base de données. Sont-elles verrouillées par défaut ?
Souvent non, et la raison est mécanique. Supabase active Row Level Security automatiquement pour les tables que vous créez en cliquant dans le Table Editor, mais pas pour celles créées en exécutant du SQL. Un builder crée les tables en exécutant du SQL, donc elles arrivent avec l'interrupteur éteint, sauf si quelque chose l'a allumé après coup.
L'aperçu marchait et l'appli déployée marche. Cela veut-il dire que la configuration est bonne ?
Non, parce que les deux marcheraient dans un cas comme dans l'autre. Une appli sans règles sur sa base se comporte exactement comme une appli avec les bonnes règles, jusqu'au moment où quelqu'un interroge la base directement au lieu de passer par vos écrans. Marcher n'est pas le même test que protégé.
Où regarder pour savoir si mon projet Bolt a ce problème ?
Ouvrez votre projet Supabase et allez dans Authentication, puis Policies. Chaque table du schéma public y est listée avec l'état de Row Level Security. Toute table affichée comme désactivée peut être lue par quiconque détient l'adresse de votre projet et votre clé publiable, et ces deux choses se trouvent dans l'appli que vous avez publiée.