Warum KI-Coding-Tools Security-Lücken hinterlassen

Warum AI-generierter Code sich in der Sicherheit unterscheidet

AI Codierungstools haben strukturelle Gründe für die Sicherheitslücken, die sie erzeugen. Es handelt sich nicht um zufällige Versäumnisse; Sie sind vorhersehbare Artefakte des Trainings und der Optimierung.

• Training data skews toward "make it work." Open-Source-Repositories und Tutorials dominieren LLM Schulungen. Das mittlere OSS Repo wurde geschrieben, um ein Problem zu lösen, und nicht, um ein Beispiel für Sicherheitsverstärkung zu sein. Ein LLM lernt die Verbreitung von Code in freier Wildbahn, nicht die Verbreitung von sicherem Code.
• Autocomplete is sticky. Wenn Sie ein Code-Snippet einfügen, das einen service_role-Schlüssel verwendet, wird es zur Vorlage für die nächste Datei. Die automatische Vervollständigung von Cursor schlägt es in einer Client-Komponente vor, wo es nie hingehörte. Das Tool macht das, wofür es optimiert ist (Geschwindigkeit), kennt aber die Sicherheitsgrenzen nicht.
• No long-term context or incident memory. Ein menschlicher Entwickler, der eine Produktionsdatenbank mit einer fehlenden WHERE-Klausel zerstört hat, trägt diese Lektion jahrelang fort. Ein LLM hat kein episodisches Gedächtnis. Jede Datei ist ein Neuanfang. Das Tool lernt nicht aus Ihrer letzten RLS Umgehung oder der Nachuntersuchung des Vorfalls Ihres Teams.
• Speed is the rewarded metric. Entwickler wählen diese Tools, weil sie schnell ausgeliefert werden. Das Latenz-Feedback erfolgt unmittelbar und direkt. Sicherheitsfeedback fehlt oder verzögert sich – eine Schwachstelle, die drei Wochen nach der Auslieferung bei einem FixVibe Scan gefunden wurde. Das LLM wurde für die Metrik optimiert, die Menschen in Echtzeit belohnen.
• Implicit trust in platform defaults. Wenn Cursor eine Vercel-App generiert, geht es davon aus, dass die Standardeinstellungen von Vercel gehärtet sind. Einige sind: Auto-HTTPS, signierte Cookies, DDoS-Schutz. Andere sind nicht: standardmäßig nein CSP, nein HSTS, freizügig CORS. Der generierte Code übernimmt Plattformannahmen, die nicht immer gerechtfertigt sind.

Lücke 1: Geheimnisse in Client-Bundles

Servicerollen-API-Schlüssel, OAuth-Tokens und private Schlüssel landen in JavaScript-Bundles, die an den Browser gesendet werden. FixVibe kennzeichnet diese als secrets.browser-storage und secrets.bundle-leak Ergebnisse. Die Schlüssel sind in Quellkarten, minimiertem Code oder Klartext JS erkennbar.

Why it happens: Cursor Das Einfügen eines Supabase-Snippets, das einen Client mit der Servicerolle initialisiert, bedeutet, dass sich der Code jetzt in der automatischen Vervollständigung befindet. Eine generierte React-Komponente fragt nach „Alle Elemente aus der Datenbank abrufen“ und Cursor schlägt den Service-Client-Import vor. Die Grenze zwischen reinem Server- und clientseitigem Code ist für LLM abstrakt.

Fix: Speichern Sie Geheimnisse in Umgebungsvariablen, die mit NEXT_PUBLIC_ gekennzeichnet sind, nur für öffentliche Schlüssel. Dienstschlüssel, private API Schlüssel und Signaturgeheimnisse müssen in src/lib/secrets.ts mit import 'server-only' leben. Verwenden Sie Serveraktionen oder API Routen, um vertrauliche Dienste aufzurufen, niemals Clientkomponenten.

Lücke 2: Fehlende oder unvollständige Sicherheit auf Zeilenebene

Supabase-Tabellen werden erstellt, ohne dass RLS aktiviert ist. Firebase Firestore-Regeln werden nie geschrieben oder bleiben im freizügigen Testmodus. Anon-Benutzer können jede Zeile lesen und schreiben. FixVibe markiert dies als baas.supabase-rls und baas.firebase-rules.

Why it happens: RLS ist eine Postgres-spezifische Funktion. Für auf Rails, Django, Laravel und Express trainierte LLMs gelten Authentifizierungsprüfungen auf Anwendungsebene als die Norm. Die Aktivierung von RLS auf Supabase erfordert explizite ALTER TABLE-Anweisungen und Richtliniendefinitionen – Muster, die in Trainingsdaten seltener vorkommen.

Fix: Für Supabase erzwingen Sie RLS mit ALTER TABLE public.table_name ENABLE ROW LEVEL SECURITY; ALTER TABLE public.table_name FORCE ROW LEVEL SECURITY; auf jeder Tabelle. Autorenrichtlinien, die Zeilen auf den authentifizierten Benutzer oder die authentifizierte Organisation beschränken. Belassen Sie für Firebase niemals die Regeln als Standardtestmodus; Schreiben Sie explizite Regeln, die für den authentifizierten Benutzer gelten.

Lücke 3: Verwirrung bei den Authentifizierungsgrenzen

Sitzungen werden clientseitig mit getSession() validiert (wodurch ein nicht verifiziertes Cookie gelesen wird). Magic-Links haben kein Ablaufdatum. JWTs überspringen aud und exp Prüfungen. Das Zurücksetzen von Passwörtern ist rückgängig zu machen. FixVibe markiert diese als active.auth-flow Ergebnisse.

Why it happens: Supabase Auth-, Clerk- und ähnliche Dienste verwalten den Sitzungsstatus, aber ihre APIs verfügen über sichere und unsichere Modi. getSession() ist praktisch, aber nicht überprüft. Der LLM sieht die Bequemlichkeit API häufiger als den sicheren in den Trainingsdaten. Die serverseitige Token-Validierung ist abstrakt und erfordert explizite HTTP-Header oder einen Middleware-Aufruf.

Fix: Verwenden Sie immer supabase.auth.getUser() serverseitig. Vertrauen Sie getSession() niemals auf geschützten Routen. Bestätigen Sie JWTs bei jeder Anfrage, indem Sie exp, aud und die Unterschrift überprüfen. Stellen Sie den Token-Ablauf für Zugriffstoken auf 1 Stunde ein und verwenden Sie Aktualisierungstoken für längere Sitzungen.

Lücke 4: Fehlende HTTP Sicherheitsheader

Nein Content-Security-Policy, nein X-Frame-Options, nein Strict-Transport-Security, nein X-Content-Type-Options. FixVibe markiert dies als headers.security-headers Ergebnisse.

Why it happens: Sicherheitsheader sind plattformspezifisch für die Bereitstellung. Cursor generiert Code für Next.js; Das Setzen von CSP erfordert eine next.config.js Optimierung, eine Middleware oder eine vercel.json Überschreibung. Diese befinden sich nicht in den Standardprojektgerüsten. Das mentale Modell „Header sind für DevOps“ ist immer noch weit verbreitet.

Fix: Setzen Sie CSP in next.config.js oder Middleware mit Nonce-Unterstützung: Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-...'; .... Fügen Sie HSTS hinzu: Strict-Transport-Security: max-age=31536000; includeSubDomains. Verwenden Sie die vercel.json-Header oder Middleware von Vercel für statische Hosts.

Lücke 5: Fehlkonfigurationen bei der Integration von Drittanbietern

Stripe Schlüssel, Sentry-Tokens, Anthropic API Schlüssel sind fest codiert oder an Repos gebunden. Analytics-Ursprünge sind zu freizügig. NPM-Abhängigkeiten sind veraltet. FixVibe Scans kennzeichnen diese als Ergebnisse unter discovery.tech-fingerprint und unseren Secrets-Checkern.

Why it happens: Integrationen werden aus Dokumentation und Tutorials eingefügt. Das LLM kopiert das Muster, einschließlich aller fest codierten Werte. Env-var-Disziplin erfordert explizite Disziplin in CI/CD – die LLM nicht erzwingen kann.

Fix: Verwenden Sie Umgebungsvariablen für alle Anmeldeinformationen von Drittanbietern. Speichern Sie Geheimnisse auf Ihrer Bereitstellungsplattform (Vercel, Netlify, Heroku oder einem Tresor). Überwachen Sie NPM-Abhängigkeiten mit npm audit monatlich. Verwenden Sie Dependabot oder Renovate für automatisierte PRs, wenn Sicherheitsupdates verfügbar sind.

Das Sanierungsmuster

Um diese Lücken zu schließen, ist kein kompletter Neuaufbau erforderlich. Das Muster ist konsistent:

1. Audit: Führen Sie FixVibe gegen Ihre Live-App aus. Aktivieren Sie für Repo-Scans die App FixVibe GitHub. Sammeln Sie die Ergebnisse – Geheimnisse, RLS, Authentifizierung, Header, Drittanbieter.
2. Härten: Behebe die Befunde mit hoher Konfidenz. Aktiviere RLS + FORCE. Verschiebe Geheimnisse in Umgebungsvariablen. Setze CSP und HSTS in der Middleware. Verwende serverseitige Auth-Validierung. Nutze den Coding-Agent-Prompt nur dort, wo Code-/Konfigurationsänderungen greifen, und folge den Operator-Schritten für DNS- oder anbietergesteuerte Fixes.
3. Monitor: Planen Sie tägliche passive Scans oder wöchentliche aktive Scans für eine verifizierte Domain. Richten Sie Webhooks für Slack ein. Jeder kritische Befund sollte innerhalb weniger Minuten nach dem Versand eine Warnung auslösen.
4. Reagieren: Wenn ein Befund auftaucht, kopiere die FixVibe-Remediation-Action, die zum Verantwortlichen des Fixes passt: einen Coding-Agent-Prompt für Code-/Konfigurationsarbeit oder Operator-Schritte für DNS, Anbieter-Konsole, Geheimnis-Rotation und manuelle Prüfung. Scanne erneut zur Bestätigung.

Wohin das Feld geht

Diese Lücken zu schließen, ist heute die Aufgabe von Teams. In den nächsten zwei bis drei Jahren verschiebt sich die Grenze: bessere Standardeinstellungen in Frameworks und Tools (Next.js Middleware-Auto-CSP, Supabase RLS als Standard), IDE-zeitiges Sicherheits-Feedback (Cursor Vorschläge, die Sie warnen, wenn Sie dabei sind, einen Dienstschlüssel in eine Client-Komponente einzufügen) und MCP-gesteuerte automatische Korrektur (Ihr Codierungsagent hat Zugriff auf FixVibe Ergebnisse und kann diese autonom beheben). FixVibes öffentliches changelog verfolgt, welche Lücken zuerst geschlossen werden.

Nächste Schritte

Die go/no-go-Checkliste vor dem Start finden Sie unter Pre-launch SaaS security checklist. Eine schrittweise Anleitung zur Härtung mit Codeausschnitten und echten Fehlermustern finden Sie unter How to secure an app built with AI coding tools.