Die 10 wichtigsten Sicherheitslücken im Code 2026

Die meisten Sicherheitsvorfälle beginnen nach wie vor mit einer Handvoll bekannter Fehlerklassen. Die Frameworks sind sicherer geworden, doch die Fehler sind nur umgezogen: in API-Handler, Hintergrundjobs, Infrastrukturcode und den Glue-Code zwischen Services. Dies ist die Liste, die wir bei jedem Audit zuerst prüfen, jeweils mit der CWE, die Sie in einem CodeAuditAgent-Bericht sehen.

1. Fehlerhafte Zugriffskontrolle (CWE-639, CWE-862)

Mit Abstand der häufigste schwerwiegende Befund: Ein Endpoint lädt einen Datensatz per ID, ohne zu prüfen, ob er dem Aufrufer gehört. Authentifizierung sagt Ihnen, wer jemand ist; die Autorisierung muss bei jeder einzelnen Abfrage stattfinden.

// Scope every lookup to the owner
const invoice = await db.invoice.findFirst({
  where: { id, userId: session.user.id },
});

2. Injection (CWE-89, CWE-78)

Per String-Verkettung gebautes SQL, Shell-Befehle und Template-Ausdrücke sind immer noch überall zu finden, meist in genau der einen Abfrage, die jemand aus Performancegründen von Hand geschrieben hat. Parametrisieren Sie die Abfrage oder übergeben Sie Argumente als Array; verketten Sie niemals Eingaben.

3. Hartcodierte Secrets (CWE-798)

Ins Repository committete API-Schlüssel, Test-Tokens, die sich als produktiv herausstellen, private Schlüssel in Konfigurationsdateien. Verschieben Sie sie in Umgebungsvariablen oder einen Secret-Manager und rotieren Sie alles, was jemals committet wurde: Das Löschen der Zeile löscht nicht die Historie.

4. Server-Side Request Forgery (CWE-918)

Jede Funktion, die eine vom Nutzer angegebene URL abruft, etwa Webhooks, Link-Vorschauen oder Importe, lässt sich auf Ihr internes Netzwerk oder den Cloud-Metadaten-Endpoint richten. Setzen Sie Hosts auf eine Allowlist, lösen Sie die IP auf und prüfen Sie sie, und blockieren Sie private Adressbereiche.

5. Cross-Site Scripting (CWE-79)

Moderne Frameworks escapen standardmäßig, daher versteckt sich XSS heute in den Ausnahmen: Props für rohes HTML, Markdown-Renderer und URLs in href-Attributen. Bereinigen Sie HTML mit einer bewährten Bibliothek und weisen Sie javascript:-URLs zurück.

6. Unsichere Deserialisierung und eval (CWE-502, CWE-95)

Pickle, YAML-Load, Java-Objekt-Streams und dynamisches eval machen aus Daten Code. Verwenden Sie stattdessen sichere Loader und per Schema validiertes JSON.

7. Schwache Kryptografie (CWE-327, CWE-330)

MD5 oder SHA-1 für Passwörter, statische IVs, Math.random() für Tokens. Nutzen Sie einen dafür entwickelten Passwort-Hash (Argon2id, bcrypt, scrypt) und eine kryptografisch sichere Zufallsquelle.

8. Open Redirects (CWE-601)

Ein next- oder returnTo-Parameter, der jede beliebige URL akzeptiert, macht Ihre Domain zur vertrauenswürdigen Startrampe für Phishing. Akzeptieren Sie nur relative Pfade derselben Origin.

9. Fehlendes Rate Limiting (CWE-307, CWE-770)

Login, Passwort-Reset, OTP und jeder Endpoint, der Sie Geld kostet (E-Mail, SMS, AI-Aufrufe), brauchen Limits pro Nutzer und pro IP. Ohne sie sind Brute-Force- und Kostenexplosions-Angriffe trivial.

10. Sicherheitsrelevante Fehlkonfiguration (CWE-16)

Wildcard-CORS mit Credentials, Debug-Modus in Produktion, ausführliche Stacktraces, zu freizügige Bucket-Policies. Im Code-Review sehen diese selten wie Bugs aus, weil sie in der Konfiguration stecken, und genau deshalb sollten sie wie Code geprüft werden.

So nutzen Sie diese Liste

• Prüfen Sie die Klassen 1 bis 3 bei jedem Pull Request; sie haben die größte Wirkung und werden am leichtesten übersehen.
• Behandeln Sie Infrastruktur- und CI-Konfiguration als Code, der geprüft wird.
• Erfassen Sie bei jedem Befund die CWE, damit sich Fixes nachverfolgen und Trends messen lassen.