Reeve Votre appli Windsurf est-elle sûre ?
Windsurf convient-il à une appli en ligne ? Le code généré va souvent bien. Ce qui passe, c'est le changement que personne n'a lu, dans un fichier non ouvert.
Les logos sont la propriété de leurs détenteurs respectifs et servent uniquement à indiquer la compatibilité.
En bref
- Une appli Windsurf est en général sûre côté code. Ce qui passe, c'est le changement que personne n'a lu : vérifiez des résultats plutôt que des diffs.
- Cherchez service_role et sk_live_ dans votre sortie de build. Cela couvre tous les fichiers touchés par l'assistant, que vous les ayez ouverts ou non.
- Row Level Security est la seule vérification qui survit à du code que vous ne lirez jamais, parce que chaque requête doit passer par la base.
Windsurf peut changer beaucoup de choses dans votre projet en une étape : plusieurs fichiers, une migration, une configuration, tout d'un coup et tout en état de marche. Le résultat est en général bon. Le problème, c'est la relecture : un changement étalé sur beaucoup de fichiers ne se lit pas comme un changement qui n'en touche qu'un, et les deux choses qui valent la peine d'être attrapées tiennent chacune sur une ligne.
Voici ce que guide après guide raconte de travers : la réponse n'est pas de lire plus attentivement. À la vitesse où ces outils travaillent, la lecture attentive ne passe pas à l'échelle. Ce qui passe à l'échelle, c'est de vérifier les deux résultats qui comptent, depuis l'extérieur, après coup.
La moitié de votre appli qui est publique quoi qu'il arrive
Toute sa façade.
Voyez cela comme une boutique. Tout ce que Windsurf construit dans votre interface est la devanture, et la devanture est remise en entier à chaque visiteur : un navigateur ne peut pas afficher une page qu'on ne lui a pas envoyée. Derrière se trouve la réserve, votre base de données, un bâtiment séparé sur internet avec sa propre adresse et sa propre serrure.
La distinction compte parce que relire du code vous renseigne sur l'intention, et l'intention n'est pas ce qui est livré. Ce qui est livré, c'est la sortie de build : un paquet de JavaScript, assemblé à partir de chaque fichier modifié, et remis à quiconque charge votre site. C'est ce paquet qui mérite d'être inspecté, et il est bien plus court à fouiller que les sources dont il provient.
Une clé dans le bundle de votre appli Windsurf, est-ce un problème ?
En général non. Cela dépend de laquelle, et les deux se ressemblent presque trait pour trait.
Une clé publiable nomme votre projet et ne fait rien d'autre :
sb_publishable_… dans les projets Supabase récents, anon dans les anciens.
Elle est faite pour être lisible et la trouver n'est pas un problème. Une clé
secrète, sb_secret_… ou l'ancienne service_role, contourne toutes les
règles que vous avez écrites et lit et écrit chaque ligne de chaque table.
La façon dont la seconde arrive mérite d'être connue, car ce n'est pas de la
négligence. Un assistant à qui l'on demande de faire parler un composant
navigateur à votre base écrit du code qui marche, et si ce code a besoin d'une
clé secrète, la clé va là où le code tourne. Vite dit clairement qu'une valeur
préfixée VITE_ est intégrée à vos sources au moment du build ; Next.js fait
pareil avec NEXT_PUBLIC_. Rien ne vous avertit, parce que du point de vue de
l'outil vous avez demandé exactement cela.
Lire quelle clé vous avez prend
environ une minute.
La seule règle qui survit à du code que vous n'avez pas lu
Row Level Security, si vos données sont dans Supabase, un interrupteur par table qui décide ligne par ligne qui peut lire quoi.
C'est pour cela que c'est la vérification qui vaut la peine. Chaque requête atteint la base, quel que soit le fichier qui l'a émise et qui a écrit ce fichier. Une règle appliquée là vaut pour toutes en même temps, y compris le code issu du changement que vous avez survolé. Aucune quantité de code non relu ne change ce qu'une requête non authentifiée récupère.
Deux choses décident si vous l'avez. Supabase active Row Level Security par défaut pour les tables créées dans le Table Editor du tableau de bord, et pas pour celles créées en exécutant du SQL, ce qui est la façon dont une migration générée les crée. Et le réglage n'est que la moitié de l'affaire : une politique qui autorise tout le monde laisse la table ouverte pendant que le tableau de bord la déclare sécurisée.
Comment vérifier votre projet Windsurf en une dizaine de minutes
Cherchez dans le build, pas dans les sources. Compilez le projet, puis
cherchez dans les fichiers de sortie service_role, sb_secret_ et sk_live_.
Une commande, et elle couvre tous les fichiers touchés par l'assistant, que vous
les ayez ouverts ou non.
Lisez les variables préfixées. Tout ce qui s'appelle VITE_… ou
NEXT_PUBLIC_… est publié. Pour chacune, demandez-vous si vous la mettriez sur
votre page d'accueil.
Ouvrez Authentication → Policies dans Supabase. Toute table listée avec Row Level Security désactivé répond à quiconque détient l'adresse de votre projet, et cette adresse est dans votre appli.
Puis regardez depuis l'extérieur. Les trois vérifications ci-dessus vous disent ce qui est configuré. Ce qu'un inconnu atteint réellement est une autre question, et c'est celle à laquelle répond notre scan gratuit : il lit votre site en ligne comme un visiteur et vous donne une note en une vingtaine de secondes, sans compte : scanner votre appli.
Que faire
- Relisez par résultat, pas par diff. À cette vitesse, lire chaque ligne modifiée n'est pas un plan.
- Ce qui est livré, c'est le bundle compilé. Le fouiller est plus rapide et plus honnête que lire les sources dont il provient.
- Une clé publiable dans le navigateur est correcte.
sb_secret_…etservice_rolesont celles à renouveler. - Un assistant met une clé là où le code qu'il a écrit en a besoin. La garder hors du navigateur n'a jamais fait partie de la demande.
- Row Level Security est la vérification qui survit à du code que vous n'avez jamais lu, parce que chaque requête doit passer par la base.
Compilez votre projet et cherchez service_role et sk_live_ dans la sortie :
cela prend une minute et donne une réponse sans ambiguïté sur le changement que
vous n'avez pas lu. Ensuite, la
checklist sécurité en 10 minutes couvre le reste.
Ce qui peut réellement mal tourner avec une appli créée avec Windsurf
Rien de tout cela ne veut dire que vous avez mal fait : ce sont les effets secondaires normaux d'un agent qui écrit beaucoup de code vite. Voici ce qu'il vaut la peine de vérifier :
Une clé secrète que l'agent a câblée pour vous
Pour qu'une intégration fonctionne du premier coup, l'agent écrit parfois la clé directement dans le code, et si ce fichier tourne dans le navigateur, n'importe qui peut la lire. Certaines clés sont faites pour être publiques, et c'est très bien. Reeve lit le code chargé de votre appli, repère les clés et vous dit lesquelles sont sûres et lesquelles doivent passer côté serveur.
Un .env committé ou un dossier .git exposé
Les clés vont dans un fichier .env qui ne part jamais en production. Mais une modification qui touche des dizaines de fichiers s'accepte vite sans lire tous les chemins : le .env finit committé, ou le dossier caché .git déployé, et tout votre historique, clés comprises, est à un téléchargement. Reeve vérifie si l'un ou l'autre est joignable depuis l'extérieur.
Votre base de données laissée ouverte (RLS désactivé)
Si votre appli stocke des données (souvent dans Supabase ou un autre Postgres), c'est la Row Level Security qui décide qui peut lire ou modifier chaque ligne. La désactiver est un moyen rapide de faire marcher une fonctionnalité pendant le développement, et elle a tendance à le rester. Reeve vérifie en comptant les lignes, jamais en les lisant.
Stockage de fichiers public
Les fichiers envoyés atterrissent dans des "buckets", et un bucket public laisse n'importe qui lister et télécharger ce qu'il contient : factures, pièces d'identité, photos privées. Reeve vérifie si vos buckets sont listables ; il ne télécharge jamais les fichiers de personne.
Source maps laissées actives
Une source map offre à qui regarde une copie lisible de votre code d'origine. Utile pendant le développement, c'est un cadeau fait aux inconnus une fois en ligne, car elle rend toutes les autres failles plus faciles à trouver. Reeve vérifie si les vôtres sont parties avec le build.
En-têtes de sécurité manquants et points d'accès ouverts
Quelques réglages indiquent aux navigateurs comment protéger vos visiteurs ; question distincte : vos points d'accès aux données répondent-ils à n'importe qui, depuis n'importe quel site ? Pris isolément c'est mineur ; ensemble, cela décide de ce qu'un inconnu peut faire de ce qu'il trouve. Reeve signale ce qui manque.
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 essaie les portes sans entrer. 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.
Windsurf est un éditeur, pas un hébergeur : il écrit et exécute du code avec vous, mais il ne déploie pas votre appli et ne la surveille pas ensuite. Cette partie vous revient, ainsi qu'à ce que l'agent a produit. Relire une grosse modification avant de l'accepter est ici la meilleure habitude, et si vous utilisez Supabase, son propre advisor signale les problèmes de base de données. Ce que Reeve ajoute, c'est le regard extérieur : ce que votre appli déployée expose réellement, en mots clairs sur lesquels agir. 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
Le code écrit par l'agent de Windsurf est-il sûr ?
C'est souvent du bon code, mais "l'agent l'a écrit" ne veut pas dire "quelqu'un a vérifié que c'était sûr". Les modifications agentiques optimisent un résultat qui marche, ce qui met parfois une clé au mauvais endroit ou désactive une règle de base de données pour contourner une erreur. Le seul moyen de savoir est de regarder ce qui est exposé. Reeve le fait gratuitement en une vingtaine de secondes.
Cascade a modifié beaucoup de fichiers d'un coup. Comment savoir ce qui est exposé ?
En lisant, le plus souvent vous ne pouvez pas. C'est la réponse honnête, et c'est pourquoi un regard extérieur aide : au lieu d'auditer un diff, Reeve examine l'appli que vous avez réellement déployée et rapporte ce qu'un inconnu peut atteindre (clés dans le navigateur, base de données ouverte, fichiers téléchargeables, .env exposé).
Comment savoir si mon appli Windsurf laisse fuir des clés d'API ?
La cause habituelle est une clé écrite dans du code qui tourne dans le navigateur, où "caché" n'existe pas. Reeve lit le code chargé de votre appli, repère les clés et vous dit lesquelles peuvent être publiques et lesquelles doivent passer côté serveur, sans jamais stocker les vraies valeurs.
Analyser mon appli Windsurf va-t-il changer 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 qu'une porte est fermée sans entrer.
Un agent a modifié des fichiers que je n'ai jamais ouverts. Comment suis-je censé relire ça ?
Pas ligne par ligne, c'est la réponse honnête. Relisez par résultat : compilez le projet et cherchez dans la sortie les formes de clés secrètes, puis regardez ce que votre base renvoie à une requête sans connexion. Les deux prennent quelques minutes et attrapent les deux échecs qui comptent vraiment, quel que soit le nombre de fichiers modifiés.
Un assistant IA met-il des secrets dans mon frontend exprès ?
Il les met là où le code qu'il a écrit en a besoin. Si un composant qui tourne dans le navigateur a été écrit pour appeler quelque chose qui exige une clé secrète, la clé doit être dans le navigateur pour que ce code marche, alors l'assistant fait en sorte que ça marche. L'instruction de la garder sur un serveur n'était pas dans la demande.
Quelle vérification unique m'en dit le plus sur mon appli ?
Si Row Level Security est activé pour chaque table, et si les politiques restreignent réellement quelqu'un. C'est la seule règle qui s'applique à toutes les requêtes quel que soit le fichier qui les a émises, donc elle survit à n'importe quelle quantité de code que vous n'avez pas lue.