Les 10 failles de sécurité des apps vibe-codées

On a scanné 198 apps construites avec des outils de vibe coding (Lovable, Bolt, Cursor, Replit). 196 avaient au moins une faille de sécurité. Voici les 10 plus courantes.

1. Clés API exposées dans le code source

La faille la plus fréquente. Les clés Supabase, Stripe, OpenAI se retrouvent dans le code frontend, visibles dans les DevTools du navigateur. Parfois même committées sur GitHub en public.

2. Headers de sécurité manquants

X-Frame-Options, Content-Security-Policy, Strict-Transport-Security — la majorité des apps vibe-codées n'ont aucun header de sécurité configuré. C'est la porte ouverte au clickjacking, XSS et injection de contenu.

3. HTTPS non forcé

L'app est accessible en HTTP (sans le "s"). Les données circulent en clair. Un simple redirect HTTP → HTTPS suffit, mais beaucoup l'oublient.

4. RLS (Row Level Security) mal configuré

Sur Supabase, si les policies RLS sont absentes ou mal écrites, n'importe qui peut lire ou modifier les données de n'importe quel utilisateur. C'est le problème de sécurité le plus grave qu'on voit sur les apps vibe-codées.

5. Fichiers sensibles accessibles publiquement

.env, .git/config, package.json — ces fichiers sont souvent accessibles via une simple URL. Ils contiennent des clés, des mots de passe, et la structure complète du projet.

6. Pas de rate limiting

Les endpoints API n'ont aucune limite de requêtes. Un attaquant peut envoyer des milliers de requêtes par seconde — brute force de mots de passe, scraping, ou simplement faire exploser ta facture cloud.

7. Dépendances vulnérables

npm audit révèle souvent des dizaines de vulnérabilités connues dans les dépendances. Les outils de vibe coding installent des packages sans vérifier leur état de sécurité.

8. CORS trop permissif

Access-Control-Allow-Origin: * autorise n'importe quel site à appeler ton API. C'est pratique en développement, dangereux en production.

9. Pas de validation des inputs

Les formulaires et endpoints API acceptent n'importe quoi. Pas de validation Zod, pas de sanitization. C'est la porte ouverte aux injections SQL, XSS, et aux données corrompues.

10. Tokens JWT sans expiration

Les tokens d'authentification n'expirent jamais. Si un token est compromis, l'attaquant a un accès permanent au compte de l'utilisateur.

Comment vérifier ton app

Le scanner gratuit Last 20% vérifie automatiquement la plupart de ces failles : SSL, headers, fichiers exposés, HTTPS, performance, conformité. Tu obtiens un score A-F avec des recommandations concrètes.