Scan de sécurité pour code généré par IA : DAST pour apps vibe-coded

Pourquoi AI-le code généré nécessite une analyse de sécurité différente

AI Les outils de codage sont formés sur des référentiels open source à grande échelle. Ces données de formation sont orientées vers make it work plutôt que vers make it secure. Quelques modèles structurels en découlent :

• Autocomplete bias. L'importation correspondante la plus proche gagne. Coller un extrait de code Supabase qui utilise la clé service_role dans un fichier fait de cette clé la suggestion de saisie semi-automatique dans le suivant, même dans les composants React côté client auxquels elle n'a jamais appartenu.
• No long-term context. Un LLM n'a aucun souvenir de votre dernier contournement RLS ou de l'autopsie de l'incident de votre équipe. Chaque fichier généré est récent et il manque souvent des modèles défensifs que les humains transporteraient dans les fichiers.
• Speed as the rewarded metric. Les utilisateurs louent la vitesse ; La formation LLM le renforce. "Générer l'authentification Next.js la plus rapide" bat "générer l'authentification Next.js la plus sécurisée" sur les signaux de retour de latence.
• Training data gaps. Les bases de code plus anciennes dominent les données de formation et sont antérieures aux valeurs par défaut de sécurité modernes (strictes CSP, SameSite=Lax, HSTS, RLS). Le code généré fait écho à des modèles qui étaient normaux en 2019 mais dangereux aujourd'hui.
• Implicit platform trust. Lorsque Cursor génère une application Vercel, il suppose que les valeurs par défaut de Vercel sont sécurisées. Certains le sont (auto-HTTPS, cookies signés). Beaucoup ne le sont pas (pas de CSP par défaut, permissif CORS, routes de débogage par défaut Next.js).

Dix classes de vulnérabilité surreprésentées dans les applications codées en ambiance

Sur des milliers d'analyses d'applications générées par AI-, les mêmes classes de résultats apparaissent de manière disproportionnée :

1. Exposed Supabase service-role keys. Un service_role JWT (démarre eyJ) engagé dans un bundle client contourne chaque RLS stratégie du projet. Cursor le complète automatiquement du mauvais côté de la limite ; la clé est livrée dans /_next/static/....
2. Missing Row-Level Security (RLS). Le modèle voit CREATE TABLE public.items et continue sans activer RLS. Les utilisateurs anonymes peuvent alors lire ou écrire n'importe quelle ligne via la clé anonyme publique. Voir baas.supabase-rls.
3. Open Firebase / Firestore rules. Les fichiers de règles générés lisent souvent allow read, write: if true; ou ignorent complètement le fichier de règles. Les règles du mode test par défaut expirent après 30 jours et verrouillent la base de données, mais uniquement si le développeur le remarque.
4. Hardcoded API keys in bundles. Stripe les clés dynamiques, Anthropic sk-ant-*, OpenAI sk-*, Google AIza* et AWS AKIA* finissent par être intégrées dans les charges utiles JS lorsque la discipline env-var expire. secrets.browser-storage les signale au niveau de la page rendue.
5. Missing Content Security Policy. Aucun en-tête de réponse Content-Security-Policy signifie que chaque script en ligne XSS est à un clic de la prise de contrôle complète du compte. CSP est abstrait ; codegen l'ignore systématiquement. headers.security-headers signale l'écart avec des conseils de correctifs spécifiques à la plate-forme de déploiement.
6. Next.js middleware misplacement. Avec la disposition src/, Next.js ne récupère que src/middleware.ts — un middleware.ts au niveau racine est ignoré en silence. L'authentification semble toujours fonctionner car les pages appellent requireAuth(), mais les en-têtes, CSP et les limites de débit n'arrivent pas.
7. IDOR via unsigned IDs. Les gestionnaires GET /api/items/[id] générés font confiance au paramètre path et ne vérifient jamais la propriété. Parcourir l’espace entier ou UUID expose les données de chaque locataire.
8. Broken auth flows. Jetons Magic-link sans expires_at ; JWT vérification qui ignore aud et exp ; appels getSession() côté client (qui lisent un cookie non vérifié) au lieu de getUser() côté serveur.
9. Debug endpoints in production. Les routes /api/debug, /api/health, /api/__nextjs_original-stack-frame ou /.next/trace génèrent des fuites internes. discovery.platform-vercel les sonde avec une validation de contenu pour éviter les faux positifs sur les SPA solutions de repli.
10. Plaintext sensitive fields. Mots de passe, API clés et PII stockés sous forme de texte brut dans Postgres, car la migration n'a pas atteint pgcrypto ou un coffre-fort externe.

DAST vs SAST : pourquoi les deux sont importants pour AI-code généré

L'analyse statique (SAST) et l'analyse dynamique (DAST) sont des compléments et non des substituts. La répartition est plus importante pour le code généré par AI- que pour le code écrit à la main.

SAST lit le code source sur le disque. Il détecte les secrets dans les fichiers sources, les appels de fonctions dangereux et les modèles risqués avant l'exécution de la build. Il ne peut pas voir la configuration d'exécution, les variables d'environnement déployées ou la façon dont un bundler a transformé votre code.

DAST accède à l'application déployée comme un utilisateur. Il voit les réponses expédiées, s'exécute sur le bundle de production et détecte la dérive de configuration entre le dépôt et le déploiement. Il trouve des clés codées en dur dans du JavaScript transpilé que SAST n'a jamais vues car elles sont entrées via une affectation process.env au moment de la construction.

For AI-generated code, DAST is essential car ce qui est livré diffère de ce que le modèle a écrit. Le regroupement, le tremblement d’arbres, la transpilation et l’inlining variable en fonction de l’environnement créent tous de nouvelles surfaces. SAST sur la source peut manquer complètement les secrets intégrés au bundle. DAST capture les deux couches. Un pipeline mature exécute SAST dans CI et DAST par rapport à l'aperçu déployé — c'est le modèle FixVibe.

Que rechercher dans un scanner de code AI-

La plupart des scanners DAST à usage général (Burp Suite, OWASP ZAP, Nessus) ont été conçus pour les applications monolithiques et les flux d'authentification traditionnels. La numérisation d'une Vercel + Supabase + Stripe AI-application générée nécessite :

• BaaS coverage. Vérifications réelles par rapport à Supabase RLS, Firebase / règles Firestore, configuration Clerk, AWS Amplify et les formes JWT émises par ces services. Les règles génériques OWASP ne savent pas quoi signaler.
• JS bundle inspection. Regex optimisé pour les formats API-key, les jetons signés et les modèles spécifiques au fournisseur (Stripe sk_live_, Anthropic sk-ant-, Supabase JWTs commençant par eyJ). Les heuristiques d'entropie génériques génèrent trop de faux positifs.
• Passive + active split. Les contrôles passifs (en-têtes, cookies, secrets, BaaS configuration, DNS) s'exécutent en toute sécurité sur n'importe quel URL. Les sondes actives (SQLi, XSS, SSTI, IDOR walking) nécessitent une limite d'autorisation car elles déclenchent des charges utiles de type attaque.
• Framework awareness. Reconnaissance du routeur d'application Next.js par rapport au routeur de pages, des réécritures Vite SPA, de la protection du déploiement Vercel, du routage des pages Cloudflare. Un scanner qui ne distingue pas un repli Vite SPA d'un vrai /_next/build-manifest.json génère du bruit.
• Rate-limit safety. Budgets de requêtes limités par analyse, comparaison ligne de base-réponse pour éviter WAF-faux positifs confus, lignes de base de sonde de chemin aléatoire pour détecter les déploiements 403 généraux.
• Authorization gating for intrusive payloads. L'envoi de charges utiles SQLi ou OS-command à un domaine que vous ne possédez pas est illégal dans la plupart des juridictions. Un véritable scanner nécessite une vérification de DNS ou HTTP-fichier avant de vous permettre d'exécuter le mode actif sur une cible.

Approche de FixVibe : analyse fondée sur des preuves, faible charge de faux positifs

FixVibe is a DAST built specifically for AI-generated web apps. The passive phase runs 200+ checks on the rendered page (headers, CSP, cookies, leaked secrets, BaaS misconfiguration, tech fingerprinting, DNS, attack-surface discovery). The active phase adds payload-firing probes (SQLi, XSS, SSTI, CORS, redirects, IDOR walking, CSRF, account enumeration, blind-SSRF) gated behind verified-domain ownership. Repo scans add code-phase checks against connected GitHub repositories. Every finding includes evidence, a CWE link, a remediation recipe, and either a coding-agent prompt or operator steps depending on who can actually apply the fix. The scan engine is open in the changelog — every new check, accuracy improvement, and false-positive fix is logged publicly.

FixVibe vs Burp Suite, ZAP et Nessus : quand chaque outil gagne

Aucun outil ne couvre tous les flux de travail. Le cadrage honnête de la place de FixVibe :

Où les outils se complètent

• Start with FixVibe passive comme référence gratuite de 30 secondes par rapport à tout aperçu de déploiement. Si rien ne fait surface, vous recevez un signal de confiance rapide.
• Move to FixVibe active sur un domaine vérifié lorsque vous souhaitez une couverture active complète (SQLi/SSTI/IDOR/etc.) sur votre propre infrastructure.
• Layer SAST (Semgrep, CodeQL, Snyk) sur le code source dans CI. SAST détecte ce que le runtime ne peut pas voir : des modèles risqués dans les chemins de code qui n'atteignent jamais le déploiement.
• Reach for Burp Suite lorsque vous avez besoin de chaînes d'attaque personnalisées (contournements d'authentification spécifiques, scénarios IDOR complexes, failles de logique métier). Burp est l'établi manuel le plus profond disponible ; FixVibe est la ligne de base automatisée la plus rapide.

Prochaines étapes

Continue avec Vibe coding security checklist pour un audit avant expédition de 44 éléments, ou passez à How to secure an app built with AI coding tools pour un renforcement étape par étape avec des extraits de code.