Passer son app vibecodée au détecteur avant qu'un autre le fasse
Une application sortie en trois soirs marche. Elle n'est pas sûre pour autant. Ce parcours repasse les endroits où une app générée saigne en premier, dans l'ordre qui compte : ce qui est déjà sorti, ce qui cède sans effort, ce qui attend un attaquant, ce qui pourrit tout seul.
Pourquoi
Le premier réflexe est presque toujours le mauvais. Quand on découvre une clé d'API dans le code envoyé au navigateur, on la retire et on recommite. Le secret reste pourtant lisible dans l'historique du dépôt, dans chaque copie faite depuis, et chez quiconque a ouvert la page. Supprimer la ligne soigne le symptôme et laisse la porte ouverte. C'est la raison d'être de ce parcours : il impose l'ordre. On révoque d'abord ce qui est déjà parti, on essaie ensuite soi-même les attaques qui ne demandent aucun outil, et on ne touche au code sophistiqué qu'après. Une application vibecodée tombe…
Quand
Avant de montrer le produit à quelqu'un qui compte. Au moment de passer un lien à un client, de mettre l'application devant de vrais comptes, ou d'accepter le premier paiement. Également quand tu hérites d'une application que tu n'as pas écrite et dont personne ne sait ce qu'elle expose. Ce n'est pas un parcours de veille : c'est un passage obligé avant une mise en ligne publique, puis une fois…
Outils inclus
- Claude Code
- Security Reviewer
- Github
- Supabase
- Zod
- Sentry