KI-Code Security Scanning: DAST für vibe-coded Apps

Warum AI-generierter Code unterschiedliche Sicherheitsscans benötigt

AI Codierungstools werden in großem Maßstab auf Open-Source-Repositories trainiert. Diese Trainingsdaten tendieren eher zu make it work als zu make it secure. Daraus ergeben sich einige Strukturmuster:

• Autocomplete bias. Der nächstgelegene passende Import gewinnt. Das Einfügen eines Supabase-Snippets, das den Schlüssel service_role verwendet, in einer Datei macht diesen Schlüssel zum Vorschlag für die automatische Vervollständigung in der nächsten – selbst in clientseitigen React-Komponenten, wo er nie hingehörte.
• No long-term context. Ein LLM hat keine Erinnerung an Ihre letzte RLS Umgehung oder den postmortalen Vorfall Ihres Teams. Jede generierte Datei ist neu und es fehlen oft Abwehrmuster, die Menschen über Dateien hinweg übertragen würden.
• Speed as the rewarded metric. Benutzer loben Geschwindigkeit; LLM Training verstärkt es. „Generieren Sie die schnellste Next.js-Authentifizierung“ schlägt „Generieren Sie die sicherste Next.js-Authentifizierung“ bei Latenz-Feedbacksignalen.
• Training data gaps. Ältere Codebasen dominieren Trainingsdaten und sind älter als moderne Sicherheitsstandards (strikt CSP, SameSite=Lax, HSTS, RLS). Der generierte Code spiegelt Muster wider, die im Jahr 2019 normal waren, heute jedoch unsicher sind.
• Implicit platform trust. Wenn Cursor eine Vercel-App generiert, geht es davon aus, dass die Standardeinstellungen von Vercel sicher sind. Einige sind (auto-HTTPS, signierte Cookies). Bei vielen ist das nicht der Fall (standardmäßig kein CSP, freizügige CORS, standardmäßige Next.js Debug-Routen).

Zehn Schwachstellenklassen sind in Vibe-codierten Apps überrepräsentiert

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

1. Exposed Supabase service-role keys. Ein service_role JWT (beginnt mit eyJ), das an ein Client-Bundle übergeben wird, umgeht alle RLS Richtlinien für das Projekt. Cursor vervollständigt es automatisch auf der falschen Seite der Grenze; Der Schlüssel wird in /_next/static/... geliefert.
2. Missing Row-Level Security (RLS). Das Modell sieht CREATE TABLE public.items und fährt fort, ohne RLS zu aktivieren. Anonyme Benutzer können dann über den öffentlichen Anonymschlüssel jede beliebige Zeile lesen oder schreiben. Siehe 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 Live-Schlüssel, Anthropic sk-ant-*, OpenAI sk-*, Google AIza* und AWS AKIA* Schlüssel werden schließlich in JS Nutzlasten integriert, wenn die Env-Var-Disziplin verfällt. Secrets in JavaScript Bundles markiert sie auf der Ebene der gerenderten Seite.
5. Missing Content Security Policy. Kein Content-Security-Policy Antwortheader bedeutet, dass jedes Inline-Skript XSS nur einen Klick von der vollständigen Kontoübernahme entfernt ist. CSP ist abstrakt; Codegen überspringt es routinemäßig. HTTP Security Headers meldet die Lücke mit der Bereitstellungsplattform-spezifischen Fehlerbehebungsanleitung.
6. Next.js middleware misplacement. Beim src/-Layout nimmt Next.js nur src/middleware.ts auf – ein middleware.ts auf Stammebene wird stillschweigend ignoriert. Die Authentifizierung scheint immer noch zu funktionieren, da die Seiten requireAuth() aufrufen, aber Header, CSP und Ratenbegrenzungen nicht landen.
7. IDOR via unsigned IDs. Generierte GET /api/items/[id]-Handler vertrauen dem Pfadparameter und überprüfen niemals den Besitz. Beim Durchlaufen der Ganzzahl oder des UUID-Leerzeichens werden die Daten jedes Mandanten verfügbar gemacht.
8. Broken auth flows. Magic-Link-Tokens ohne expires_at; JWT-Verifizierung, die aud und exp überspringt; clientseitige getSession()-Aufrufe (die ein nicht verifiziertes Cookie lesen) anstelle von serverseitigen getUser()-Aufrufen.
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. Passwörter, API Schlüssel und PII werden als Klartext in Postgres gespeichert, da die Migration weder pgcrypto noch einen externen Tresor erreicht hat.

DAST vs. SAST: Warum beide für AI-generierten Code wichtig sind

Statische Analyse (SAST) und dynamische Analyse (DAST) sind Ergänzungen, kein Ersatz. Die Aufteilung ist für AI-generierten Code wichtiger als für handgeschriebenen Code.

SAST liest den Quellcode auf der Festplatte. Es erkennt Geheimnisse in Quelldateien, gefährliche Funktionsaufrufe und riskante Muster, bevor der Build ausgeführt wird. Es kann keine Laufzeitkonfiguration, bereitgestellte Umgebungsvariablen oder die Art und Weise sehen, wie ein Bundler Ihren Code transformiert hat.

DAST trifft die bereitgestellte Anwendung wie ein Benutzer. Es sieht versendete Antworten, führt es mit dem Produktionspaket aus und erkennt Konfigurationsabweichungen zwischen Repo und Bereitstellung. Es findet fest codierte Schlüssel in transpiliertem JavaScript, die SAST nie gesehen hat, weil sie zur Erstellungszeit über eine process.env Zuweisung eingegeben wurden.

For AI-generated code, DAST is essential weil sich die Art der Schiffe von dem unterscheidet, was das Modell geschrieben hat. Durch Bündelung, Tree-Shaking, Transpilation und umgebungsvariables Inlining entstehen neue Oberflächen. SAST in der Quelle kann im Bundle eingebettete Geheimnisse vollständig übersehen. DAST fängt beide Ebenen ein. Eine ausgereifte Pipeline führt SAST in CI und DAST gegen die bereitgestellte Vorschau aus – das ist das FixVibe-Muster.

Worauf Sie bei einem AI-Code-Scanner achten sollten

Die meisten Allzweck-DAST-Scanner (Burp Suite, OWASP ZAP, Nessus) wurden für monolithische Apps und traditionelle Authentifizierungsabläufe entwickelt. Das Scannen einer Vercel + Supabase + Stripe AI-generierten App erfordert:

• BaaS coverage. Echte Prüfungen gegen Supabase RLS, Firebase / Firestore-Regeln, Clerk-Konfiguration, AWS Amplify und die JWT Formen, die diese Dienste ausgeben. Generische OWASP-Regeln wissen nicht, was sie kennzeichnen sollen.
• 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. Passive Prüfungen (Header, Cookies, Geheimnisse, BaaS Konfiguration, DNS) werden sicher gegen jedes URL ausgeführt. Aktive Sonden (SQLi, XSS, SSTI, IDOR Walking) erfordern eine Autorisierungsgrenze, da sie Nutzlasten im Angriffsstil abfeuern.
• 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. Das Senden von SQLi- oder OS-Befehlsnutzdaten an eine Domain, die Ihnen nicht gehört, ist in den meisten Gerichtsbarkeiten illegal. Ein echter Scanner erfordert eine DNS oder HTTP-Dateibesitzüberprüfung, bevor Sie den aktiven Modus für ein Ziel ausführen können.

FixVibes Ansatz: evidenzbasiertes Scannen, geringe Falsch-Positiv-Last

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 und Nessus: wenn jedes Tool gewinnt

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.

Wo sich die Tools gegenseitig ergänzen

• 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 auf einer verifizierten Domain, wenn Sie eine vollständige aktive Abdeckung (SQLi/SSTI/IDOR/etc.) Ihrer eigenen Infrastruktur wünschen.
• Layer SAST (Semgrep, CodeQL, Snyk) zum Quellcode in CI. SAST fängt, was die Laufzeit nicht sehen kann – riskante Muster in Codepfaden, die nie die Bereitstellung erreichen.
• Reach for Burp Suite wenn Sie benutzerdefinierte Angriffsketten benötigen (spezifische Authentifizierungsumgehungen, komplizierte IDOR Szenarien, Fehler in der Geschäftslogik). Burp ist die tiefste verfügbare manuelle Werkbank; FixVibe ist die schnellste automatisierte Basislinie.

Nächste Schritte

Continue mit Vibe coding security checklist für ein 51-Punkte-Audit vor dem Versand oder springen Sie zu How to secure an app built with AI coding tools für eine schrittweise Härtung mit Codeausschnitten.