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

The same finding classes show up disproportionately in AI-generated apps:

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 Supabase Row-Level Security.
3. Open Firebase / Firestore rules. Generated rules files often read allow read, write: if true; or skip the rules file entirely. Test-mode rules let anyone read and overwrite data until someone replaces them.
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 in JavaScript Bundles 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. HTTP 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. Generated /api/debug, /api/health, /api/__nextjs_original-stack-frame, or /.next/trace routes leak internals. FixVibe reports them only with evidence that they really are exposed (Vercel-Specific Exposure).
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. Recognising real API-key formats — Stripe sk_live_, Anthropic sk-ant-, Supabase service-role keys — and telling a secret key from a publishable one. Generic pattern matching throws too many false positives.
• 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. Recognising Next.js App Router vs Pages Router, Vite SPA rewrites, Vercel deployment-protection, Cloudflare Pages routing. A scanner that doesn't understand how these platforms answer unknown paths generates noise.
• Rate-limit safety. Bounded request budgets per scan, and findings that require positive evidence — a blanket 403 from a WAF is not proof a file exists.
• 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 230+ 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

No single tool covers every workflow. For a sourced side-by-side of FixVibe, Burp Suite, ZAP, Snyk, Semgrep and Aikido, with a decision matrix, see choosing a security scanner for AI-built apps.

Où les outils se complètent

• Start with FixVibe passive as a free baseline against any deploy preview — it usually finishes in under a minute. If nothing surfaces, you have a fast confidence signal.
• 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 51 é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.