Die Security-Checkliste für KI-generierten Code

KI-Coding-Tools sind keine Security Engineers. Sie vervollständigen Muster. Sie erzeugen Code, der wie Code aussieht, den sie im Training gesehen haben. Und der meiste Code im Training wurde nicht für Angreifer geschrieben.

Das ist keine Kritik an den Tools. Es ist eine architektonische Realität. Claude, Cursor, Copilot und Bolt generieren Code, der die beschriebenen Anforderungen erfüllt. Wenn “und bitte sicher” nicht Teil der Anforderung ist, bekommen Sie auch keine echte Sicherheit.

Die Checkliste unten nutzen wir beim Onboarding einer neuen KI-generierten Codebasis. Sie orientiert sich an den OWASP Top 10 und deckt die Fehler ab, die wir am häufigsten sehen. Arbeiten Sie sie systematisch durch. Die meisten Probleme lassen sich in Stunden beheben, sobald sie sichtbar sind.

1. Injection verhindern

Check: Sind alle Datenbankabfragen parametrisiert?

SQL Injection ist bei KI-generiertem Code immer noch eine der häufigsten Schwachstellen. Der natürliche Weg, Queries mit String-Formatierung zu bauen, ist leider auch der gefährliche Weg.

# Gefährlich: wird von KI-Tools häufig generiert
cursor.execute(f"SELECT * FROM users WHERE email = '{email}'")

# Sicher: parametrisierte Query
cursor.execute("SELECT * FROM users WHERE email = %s", (email,))

Aktion: Suchen Sie jede SQL-Query in der Codebasis. Jede Query, die über String-Formatierung oder Verkettung gebaut wird, ist eine Schwachstelle. Ersetzen Sie sie durch parametrisierte Queries oder ein ORM, das Parametrisierung standardmäßig übernimmt.

Auch prüfen: NoSQL Injection, zum Beispiel MongoDB-Operatoren in User Input, Command Injection durch Shell-Befehle aus User Input und LDAP Injection, falls relevant.

2. Authentifizierung

Check: Sind alle nicht öffentlichen Endpunkte geschützt?

KI-Tools erzeugen Login-Endpunkte oft korrekt. Weniger zuverlässig sind sie darin, diese Authentifizierung überall konsequent anzuwenden.

Aktion: Listen Sie jeden Endpunkt der Anwendung auf. Prüfen Sie für jeden Endpunkt zwei Dinge: Erstens, braucht er Authentifizierung, wo er sie brauchen sollte? Zweitens, prüft er, ob der angemeldete Nutzer genau diese Ressource sehen oder ändern darf?

Der zweite Check ist Autorisierung. Dort fallen die meisten Codebasen durch. Authentifizierung sagt, wer der Nutzer ist. Autorisierung sagt, was er tun darf. Ein Endpunkt, der beliebige Nutzerdaten an jeden angemeldeten Nutzer ausliefert, hat kein Authentifizierungsproblem. Er hat ein Autorisierungsproblem.

Auch prüfen:

• Passwörter werden mit bcrypt, scrypt oder Argon2 gehasht, nicht mit MD5, SHA1 oder plain SHA256
• Passwort-Reset-Tokens sind kryptografisch zufällig und verfallen nach Nutzung
• JWTs nutzen starke Signaturalgorithmen, zum Beispiel RS256 oder ES256, nicht HS256 mit schwachem Secret
• Session-Tokens werden beim Logout invalidiert

3. Sensitive Daten

Check: Wo liegen Secrets?

Das ist der häufigste kritische Fund in KI-generierten Codebasen: API Keys, Datenbankpasswörter und JWT-Secrets direkt im Repository. Manchmal in der Hauptdatei der Anwendung. Manchmal in einer .env, die versehentlich mit Git getrackt wird.

Aktion: Führen Sie git log -p | grep -i "api_key\|secret\|password\|token" aus, um historische Commits mit Secrets zu finden. Wenn Sie etwas finden, rotieren Sie diese Secrets sofort. Sie müssen als kompromittiert gelten.

Danach:

• .env in .gitignore aufnehmen, falls noch nicht passiert
• Alle Secrets in Environment Variablen verschieben, die aus einem Secret Manager geladen werden
• Ein Tool wie detect-secrets oder truffleHog als Pre-Commit Hook nutzen
• Die aktuelle Umgebung auf Secrets prüfen, die rotiert werden sollten

Auch prüfen:

• Sensitive Daten wie Passwörter, Kreditkarten oder Ausweisnummern werden nicht geloggt
• API Responses enthalten nicht mehr Daten, als der Client braucht
• Fehlermeldungen verraten keine Stack Traces, Datenbankstruktur oder internen Pfade

4. Security Misconfiguration

Check: Sind Debug-Modi in Produktion deaktiviert?

KI-generierte Anwendungen laufen oft standardmäßig im Entwicklungsmodus. Entwicklungsmodus zeigt detaillierte Fehlermeldungen, interne Stack Traces und manchmal interaktive Debugger. Für Entwicklung nützlich, in Produktion gefährlich.

Aktion: Prüfen Sie, dass DEBUG=False oder das Framework-Äquivalent in Produktion gesetzt ist. Prüfen Sie, dass Ihr Webframework keine detaillierten Fehlerseiten an Nutzer zurückgibt. Prüfen Sie, dass Admin-Oberflächen nicht öffentlich erreichbar sind.

Auch prüfen:

• CORS ist konkret konfiguriert, nicht mit *
• Security Header sind gesetzt: X-Content-Type-Options, X-Frame-Options, Content-Security-Policy
• Standard-Zugangsdaten sind bei allen Services geändert
• Unnötige Ports und Services sind nicht exponiert

5. Rate Limiting und Brute-Force-Schutz

Check: Haben Login- und Auth-Endpunkte Rate Limiting?

KI-generierte Login-Endpunkte verarbeiten oft jede Anfrage ohne Limit. Ein Angreifer kann Millionen Passwort- oder E-Mail-Kombinationen testen, ohne Schutz auszulösen.

Aktion: Fügen Sie Rate Limiting für Login, Passwort-Reset und Registrierung hinzu. Die genauen Limits hängen vom Produkt ab. Ein sinnvoller Startpunkt: 10 Versuche pro IP in 15 Minuten, danach exponentielles Backoff.

Auch prüfen:

• Account Lockout nach wiederholten fehlgeschlagenen Login-Versuchen
• CAPTCHA oder eine gleichwertige Hürde für öffentliche Formulare
• Rate Limiting auf API-Endpunkten, passend zu ihren Kosten

6. Verwundbare Dependencies

Check: Wann haben Sie Ihre Dependencies zuletzt geprüft?

KI-Tools erzeugen Requirements-Dateien mit Versionen, die zum Trainingszeitpunkt oder im Kontext nahelagen. Security-Lücken werden ständig gefunden und gepatcht. Ihre Dependencies sind wahrscheinlich nicht aktuell.

Aktion: Führen Sie jetzt einen Dependency Audit aus:

# Python
pip audit

# Node.js
npm audit

# Beide
snyk test

Beheben Sie kritische und hohe Schwachstellen zuerst. Mittlere und niedrige Schwachstellen bewerten Sie im Kontext Ihrer Anwendung.

Auch prüfen:

• Dependencies sind in Produktion auf konkrete Versionen gepinnt, nicht nur auf Ranges
• Sie haben einen Prozess, um Security Advisories für Dependencies zu bekommen
• Ungenutzte Dependencies sind entfernt

7. Input-Validierung

Check: Wird jeder User Input serverseitig validiert?

Clientseitige Validierung im Browser verbessert die Nutzererfahrung. Sie ist keine Security-Maßnahme. Alles, was nur im Browser validiert wird, kann mit direkten HTTP Requests umgangen werden.

Aktion: Jede Eingabe von außen wird serverseitig validiert: Typ, Format, Länge, Wertebereich und erlaubte Werte. Nutzen Sie eine Schema-Bibliothek wie Pydantic, Zod oder Joi statt manueller Checks. Damit übersehen Sie weniger Fälle.

Auch prüfen:

• File Uploads prüfen den Dateityp serverseitig, nicht nur anhand der Extension
• Hochgeladene Dateien liegen außerhalb des Web Root, wenn Ausführung gefährlich wäre
• URL-Parameter und Pfadsegmente werden validiert, nicht nur Request Bodies

8. Error Handling

Check: Verraten ungefangene Exceptions Informationen an Nutzer?

Ein Stack Trace in einer User Response ist schlechte Nutzererfahrung und ein Security-Problem. Er verrät Tech Stack, Dateipfade und manchmal Daten aus dem Speicher.

Aktion: Implementieren Sie einen globalen Error Handler. Intern wird der komplette Fehler geloggt. An Nutzer geht eine generische Meldung mit Referenz-ID.

# Jeder nutzerseitige Fehler sollte so aussehen
@app.exception_handler(Exception)
async def global_exception_handler(request, exc):
    logger.error("unhandled_exception", error=str(exc), trace=traceback.format_exc())
    return JSONResponse(
        status_code=500,
        content={"error": "Internal server error", "reference": generate_reference_id()}
    )

So arbeiten Sie die Checkliste ab

Versuchen Sie nicht, alles auf einmal zu beheben. Priorisieren Sie nach Impact:

1. Sofort, heute: Secrets im Repository, SQL Injection, Debug Mode in Produktion
2. Diese Woche: Authentifizierungs- und Autorisierungslücken, fehlendes Rate Limiting, verwundbare Dependencies
3. Dieser Sprint: Input-Validierung, Error Handling, Security Header, CORS

Jeder Punkt auf dieser Liste gehört in einen Production-Readiness-Review mit klarer Schwere und einem Fix Owner. Wenn Sie diesen Review von Senior Engineers durchführen lassen wollen, starten Sie mit unserem Production-Ready-Angebot.

Security ist kein einmaliger Fix. Sie ist eine Praxis. Starten Sie mit dieser Checkliste, beheben Sie die Funde, und prüfen Sie neuen Code vor dem Shipping gegen diese Kategorien.