OWASP Top 10 2025: Was sich ändert und welche Risiken ein Scanner erkennt

Was sind die OWASP Top 10 2025?

Die OWASP Top 10 2025 sind eine Rangliste von zehn Risikokategorien für Webanwendungen, von denen jede verwandte CWE-Schwächen bündelt. Für diese Ausgabe hat OWASP 589 CWEs ausgewertet und 248 davon in die zehn Kategorien übernommen, mit einer Obergrenze von 40 pro Kategorie. Acht Kategorien stammen aus Testdaten, die Unternehmen wie Semgrep, Sonar, Veracode, Contrast Security und Bugcrowd beigesteuert haben. Die anderen zwei kommen aus einer Community-Umfrage, weil OWASP die Daten allein für unvollständig hält.

Sicherheitsteams nutzen die Liste als gemeinsames Vokabular. Schulungen, Checklisten für Code-Reviews, Scanner-Berichte und Audit-Nachweise sind oft nach ihren Kategorien geordnet, deshalb wirkt eine neue Ausgabe bis in Tools, Richtlinien und Audits hinein.

Welche zehn Kategorien gibt es?

Die zehn Kategorien der OWASP Top 10 2025 sind Broken Access Control, Security Misconfiguration, Software Supply Chain Failures, Cryptographic Failures, Injection, Insecure Design, Authentication Failures, Software or Data Integrity Failures, Security Logging and Alerting Failures und Mishandling of Exceptional Conditions. OWASP veröffentlicht sie auf Englisch, und Teams nennen sie auch so.

Was hat sich seit der Liste von 2021 geändert?

Für ein Entwicklungsteam zählen vier Änderungen: Die Lieferkette bekommt eine eigene Kategorie, SSRF wandert in die Zugriffskontrolle, Fehlerbehandlung wird zur Kategorie, und Fehlkonfiguration steigt auf Platz zwei.

• Software Supply Chain Failures (A03). Die Kategorie Vulnerable and Outdated Components von 2021 deckte bekannte CVEs in Ihren Abhängigkeiten ab. Die Kategorie von 2025 umfasst Ausfälle und Kompromittierungen im Prozess, in dem Software gebaut, verteilt oder aktualisiert wird, und OWASP nennt den Build-Server und die CI/CD unter den Dingen, die zu schützen sind. Ein Scan des Lockfiles reicht nicht mehr: Auch die Pipeline, die Ihren Code baut, gehört dazu. Die Hintergrundnotizen von OWASP geben dieser Kategorie die höchste durchschnittliche Häufigkeit der zehn.
• SSRF kommt zu Broken Access Control (A01). Server-Side Request Forgery war 2021 A10. Jetzt zählt sie als eine der 40 Schwächen von Broken Access Control.
• Mishandling of Exceptional Conditions (A10). Die neue Kategorie betrifft Programme, die ungewöhnliche und unvorhersehbare Situationen nicht verhindern, nicht erkennen und nicht richtig behandeln. Zu ihren 24 Schwächen gehören Fehlermeldungen, die sensible Daten preisgeben (CWE-209), NULL-Pointer-Dereferenzierungen (CWE-476) und Code, der im Fehlerfall offen statt sicher scheitert (CWE-636).
• Security Misconfiguration (A02) steigt von Platz fünf auf Platz zwei. Die Definition von OWASP nennt jetzt Cloud-Dienste neben falsch eingerichteten Systemen und Anwendungen.

Zwei Namen ändern sich: Aus Identification and Authentication Failures wird Authentication Failures, aus Security Logging and Monitoring Failures wird Security Logging and Alerting Failures. Denial of Service, umbenannt in Lack of Application Resilience, steht im Abschnitt „Next Steps“ von OWASP, außerhalb der zehn.

Welcher Open-Source-Scanner findet welches Risiko?

Statische Open-Source-Scanner decken Injection und Cryptographic Failures weitgehend ab, sechs weitere Kategorien teilweise und wenig von Insecure Design und Security Logging and Alerting Failures. Die Tabelle ist unsere Lesart des dokumentierten Umfangs jedes Tools, abgeglichen mit den Kategorieseiten von OWASP, gelesen am 13. November 2026.

Opengrep, der LGPL-2.1-Fork von Semgrep, deckt mehr als 30 Sprachen ab und führt Semgrep-Regeln unverändert aus. Sein README beschreibt eine Taint-Analyse innerhalb einer Datei, deshalb steht in der Injection-Zeile „Datenflüsse über Dateigrenzen hinweg“. Trivy liest Abhängigkeiten, Infrastructure as Code, Secrets und Lizenzen, und unser Test von Open-Source-SCA-Tools zeigt, was es und OSV-Scanner in einem echten Lockfile finden. Gitleaks findet Passwörter, API-Schlüssel und Tokens in Dateien und in der Git-Historie; fest eingetragene Zugangsdaten (CWE-798) gehören in der Liste von 2025 zu A07, und unser Vergleich von Open-Source-Secret-Scannern behandelt das ausführlich. zizmor analysiert GitHub Actions statisch, mit Prüfungen wie template-injection, unpinned-uses, dangerous-triggers, excessive-permissions und cache-poisoning, die in A03 und A08 hineinreichen.

Keines dieser Tools sieht ein bösartiges Paket, für das es noch kein Advisory gibt, und genau durch diese Lücke geht Slopsquatting, der Angriff über Paketnamen, die sich ein KI-Modell ausdenkt.

Warum übersehen Scanner das Risiko Nummer eins?

Statische Scanner übersehen den Kern von Broken Access Control, weil die Schwachstelle eine fehlende Prüfung ist, und eine fehlende Prüfung hat kein Muster. Ein Scanner kann eine Nutzereingabe bis zu einer gefährlichen Funktion verfolgen. Er hat keine Quelle für die Regel, dass eine Rechnung genau einem Kunden gehört.

Die Regelsätze zeigen es. Am 13. November 2026 haben wir die Regeln des Community-Regelsatzes von Opengrep gezählt, eines Stands der Semgrep-Regeln vom Januar 2025: 2.007 Regeln, von denen 1.354 eine OWASP-Kategorie von 2021 tragen. Injection hat 384 davon. Broken Access Control hat 228, aber 114 davon prüfen Zugriffseinstellungen von Cloud-Ressourcen, vor allem in Terraform, und andere decken Path Traversal, CSRF und Open Redirects ab. Die drei Schwächen, die Autorisierung selbst beschreiben, CWE-639 (Umgehung der Autorisierung über einen vom Nutzer gesteuerten Schlüssel), CWE-862 (fehlende Autorisierung) und CWE-863 (falsche Autorisierung), tauchen in vier Regeln auf. Drei davon lesen Anwendungscode, jede für ein einziges Framework: ein nicht eingegrenztes find in Ruby on Rails, ein ASP.NET-Core-Controller ohne Autorisierungsattribut, native Datenoperationen in Salesforce Apex. Sie bemerken eine fehlende Prüfung; keine kann sagen, ob eine vorhandene Prüfung die richtige ist.

OWASP schrieb schon 2017, dass SAST- und DAST-Tools das Fehlen einer Zugriffskontrolle erkennen, aber nicht prüfen können, ob sie funktioniert, wenn sie vorhanden ist. So sieht das in einer Express-Route aus:

// GET /api/invoices/:id
app.get("/api/invoices/:id", requireLogin, async (req, res) => {
  const invoice = await db.invoice.findUnique({ where: { id: req.params.id } });
  res.json(invoice);
});

Die Route verlangt einen Login, die Abfrage ist parametrisiert, die Eingabe erreicht nie eine gefährliche Funktion. Ein Scanner hat nichts zu melden. Trotzdem kann jeder angemeldete Kunde jede Rechnung lesen, indem er die Nummer in der URL ändert, eine Insecure Direct Object Reference. Die Korrektur ist eine Bedingung, where: { id: req.params.id, customerId: req.user.customerId }, und schreiben kann sie nur, wer weiß, dass Rechnungen Kunden gehören.

Insecure Design liegt noch weiter außer Reichweite. Die OWASP-Seite sagt es klar: Ein unsicheres Design lässt sich durch keine perfekte Implementierung beheben, weil die nötigen Sicherheitskontrollen nie geschaffen wurden. Ein Checkout, der eine negative Menge akzeptiert, besteht jeden Scanner, wie unser Gang durch den Warenkorb für 0 Euro zeigt. Die ganze Familie behandeln wir in Fehler in der Geschäftslogik von KI-generiertem Code.

Wie testet man fehlerhafte Zugriffskontrolle?

Fehlerhafte Zugriffskontrolle testen Sie mit einem Test, der die verbotene Aktion versucht und eine Ablehnung erwartet, einer pro Rolle und pro Objekt, das jemandem gehört. Die OWASP-Seite von 2025 verlangt genau das: Entwickler und QA sollten funktionale Zugriffskontrolle in ihre Unit- und Integrationstests aufnehmen.

test("a customer cannot read another customer's invoice", async () => {
  const res = await request(app)
    .get(`/api/invoices/${aliceInvoice.id}`)
    .set("Authorization", tokenFor(bob));
  expect(res.status).toBe(404);
});

Ein solcher Test ist Beweis und Schutz zugleich. Vor der Korrektur schlägt er fehl, und das beweist, dass die Lücke in Ihrem Code existiert und nicht nur in der Theorie. Nach der Korrektur läuft er durch und bleibt in der Suite, damit die nächste Änderung das Loch nicht wieder öffnet. Der Aufwand besteht darin, zu wissen, welche Objekte wem gehören, und genau dieses Wissen fehlt einem Scanner.

Drei Gewohnheiten bringen viel:

1. Standardmäßig verweigern. Jede neue Route beginnt geschlossen, und Zugriff gibt es nur über eine ausdrückliche Prüfung, die den Eigentümer oder die Rolle nennt.
2. Jede Abfrage auf den Nutzer eingrenzen. Datensätze über den aktuellen Nutzer oder Mandanten abfragen, nie über eine nackte ID aus der Anfrage.
3. Ein Ablehnungstest pro sensiblem Objekt. Rechnungen, Dokumente, Konten, alles mit einem Eigentümer bekommt einen Test, in dem der falsche Nutzer abgewiesen wird.

Was bedeuten die OWASP Top 10, wenn KI-Agenten den Code schreiben?

Die Kategorien ändern sich nicht, wenn Coding-Agenten wie Claude Code, Cursor, GitHub Copilot oder OpenAI Codex den Code schreiben, wohl aber Menge und Tempo. Ein Team, das mehr Änderungen pro Woche ausliefert, braucht die Scanner auf jeder Änderung und die Prüfung der Zugriffskontrollen auf jedem neuen Endpunkt, denn ein Agent schreibt eine funktionierende Route genauso leicht, wie er eine Eigentümerprüfung auslässt, die ihm nie beschrieben wurde.

Dieselben Agenten können auch die Verteidigungsarbeit übernehmen. Ein Agent, der die Codebasis liest, kann jeden Endpunkt erfassen, fragen, welche Rollen ihn erreichen, den Ablehnungstest schreiben, ihn ausführen und zeigen, ob er fehlschlägt. Das ist der Teil der OWASP Top 10, den Scanner liegen lassen, und es ist Arbeit, die ein Coding-Agent im selben Tempo erledigen kann, in dem er Code schreibt. Unser Leitfaden zur Sicherheit von KI-Coding-Agenten behandelt die andere Seite: was der Agent selbst ausführen darf.

Wo passt CybeDefend hinein?

CybeDefend Open Source startet bald und deckt beide Hälften dieses Artikels ab. Ein Befehl in Ihrem Coding-Agenten, /cybedefend, fährt ein vollständiges Audit in zwei Ebenen. Zuerst die AppSec-Scanner, Open Source, darunter Opengrep, Trivy, Gitleaks und zizmor, für Code, Abhängigkeiten, Secrets, Infrastructure as Code, CI/CD und Container: die musterförmigen Risiken aus der Tabelle oben. Sie behalten die, die Sie wollen, und fügen Ihre eigenen hinzu.

Danach der KI-Scanner, den Ihr Coding-Agent ausführt. Scanner suchen nach Mustern. Der KI-Scanner liest, was Ihr Code tun soll, und findet, wo er bricht, in der Geschäftslogik, bei Zugriffsrechten und bei Lücken, die erst zur Laufzeit sichtbar werden: die Zeilen A01, A06 und A07. Er belegt jede Lücke mit einem Exploit, der als Test in Ihrer eigenen Suite geschrieben ist, wie der oben. Kein zusätzliches Modell und kein API-Schlüssel: Die KI ist der Coding-Agent, den Sie schon nutzen.

Unter beiden Ebenen liegt unsere ganze Plattform, ein agentisches ASPM. Sie hält jeden Befund in einer einzigen Liste, und ihre Sicherheitsberichte ordnen Befunde den OWASP Top 10 und den CWE Top 25 zu. Um das Audit zum Start auf Ihrem eigenen Code zu fahren, tragen Sie sich in die Warteliste von CybeDefend Open Source ein.

Häufige Fragen

Was ist neu in den OWASP Top 10 2025?

Zwei Kategorien sind neu: Software Supply Chain Failures auf A03, die das alte Vulnerable and Outdated Components auf Build-Systeme und CI/CD erweitert, und Mishandling of Exceptional Conditions auf A10. Server-Side Request Forgery ist in Broken Access Control aufgegangen, und Security Misconfiguration ist von Platz fünf auf Platz zwei gestiegen.

Was steht auf Platz eins der OWASP Top 10 2025?

Broken Access Control, wie schon 2021. Die Kategorie bündelt 40 Schwächen, von Path Traversal und CSRF bis zu fehlender Autorisierung und Insecure Direct Object References, und seit 2025 gehört auch SSRF dazu.

Ist SSRF noch in den OWASP Top 10?

Ja, innerhalb von A01 Broken Access Control. 2021 war SSRF eine eigene Kategorie, A10; die Ausgabe von 2025 hat sie in die Zugriffskontrolle verschoben.

Reicht ein SAST-Tool für die ganzen OWASP Top 10?

Nein. Ein SAST-Tool deckt Injection und Cryptographic Failures gut ab und Teile mehrerer anderer Kategorien. Risiken in Abhängigkeiten und Pipelines brauchen ein SCA-Tool und einen CI/CD-Scanner, und fehlerhafte Zugriffskontrolle und unsicheres Design brauchen Tests und Reviews von jemandem, der die Regeln der Anwendung kennt.

Wie oft werden die OWASP Top 10 aktualisiert?

Einen festen Rhythmus gibt es nicht. Die Ausgabe von 2025 ist die achte, vier Jahre nach der Liste von 2021.

Ist CybeDefend Open Source?

Seine Open-Source-Ausgabe, CybeDefend Open Source, startet bald: unsere ganze Plattform, ein agentisches ASPM, kostenlos auf Ihren eigenen Servern. Der Befehl /cybedefend verkettet die Open-Source-AppSec-Scanner und einen KI-Scanner, den Ihr Coding-Agent ausführt, und hält jeden Befund in einer einzigen Liste. Tragen Sie sich in die Warteliste von CybeDefend Open Source ein.