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

Bei Tausenden von Scans von AI-generierten Apps werden dieselben Ergebnisklassen überproportional häufig angezeigt:

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 baas.supabase-rls.
3. Open Firebase / Firestore rules. Generierte Regeldateien lauten häufig allow read, write: if true; oder überspringen die Regeldatei vollständig. Die Standardregeln für den Testmodus laufen nach 30 Tagen ab und sperren die Datenbank, jedoch nur, wenn der Entwickler dies bemerkt hat.
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.browser-storage 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. headers.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. Generierte Routen /api/debug, /api/health, /api/__nextjs_original-stack-frame oder /.next/trace. discovery.platform-vercel prüft sie mit einer Inhaltsvalidierung, um Fehlalarme bei SPA Fallbacks zu vermeiden.
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. Optimierter regulärer Ausdruck für API-Schlüsselformate, signierte Token und anbieterspezifische Muster (Stripe sk_live_, Anthropic sk-ant-, Supabase JWTs beginnend mit eyJ). Generische Entropie-Heuristiken werfen zu viele Fehlalarme aus.
• 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. Erkennen von Next.js App Router vs. Pages Router, Vite SPA Umschreibungen, Vercel Bereitstellungsschutz, Cloudflare Pages-Routing. Ein Scanner, der einen Vite SPA-Fallback nicht von einem echten /_next/build-manifest.json unterscheidet, erzeugt Rauschen.
• Rate-limit safety. Begrenzte Anforderungsbudgets pro Scan, Baseline-Antwort-Vergleich zur Vermeidung von WAF-verwirrten Fehlalarmen, randomisierte Path-Probe-Baselines zur Erkennung pauschaler 403-Bereitstellungen.
• 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 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 und Nessus: wenn jedes Tool gewinnt

Kein einzelnes Tool deckt jeden Arbeitsablauf ab. Die ehrliche Formulierung, wo FixVibe passt:

Wo sich die Tools gegenseitig ergänzen

• Start with FixVibe passive als kostenlose 30-Sekunden-Baseline für jede Bereitstellungsvorschau. Wenn nichts auftaucht, haben Sie ein schnelles Vertrauenssignal.
• 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 44-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.