OWASP Top 10 Mapping: Von 2021 auf 2025

Warum dieses Mapping jetzt wichtig ist

Die OWASP Top 10:2025 ist die erste größere Überarbeitung seit vier Jahren. Wer Pentest-Berichte an die 2021er-Kategorien knüpft, Finding-Templates danach benannt oder Compliance-Nachweise darauf aufgebaut hat, muss jetzt sauber übersetzen. Zwei Kategorien sind neu, zwei wurden umbenannt, eine alte ist als eigenständige Position verschwunden, und die Reihenfolge hat sich spürbar verschoben. Das sieht auf den ersten Blick wie Kosmetik aus — ist es aber nicht, sobald es um Testpläne, Abnahmekriterien oder ISMS-Referenzen geht.

Dieser Beitrag ist eine Ergänzung zu unserem Überblick zur OWASP Top 10 aus 2021 und beschränkt sich bewusst auf die Deltas.

Die OWASP Top 10:2025 im Überblick

A01:2025  Broken Access Control
A02:2025  Security Misconfiguration
A03:2025  Software Supply Chain Failures
A04:2025  Cryptographic Failures
A05:2025  Injection
A06:2025  Insecure Design
A07:2025  Authentication Failures
A08:2025  Software or Data Integrity Failures
A09:2025  Security Logging and Alerting Failures
A10:2025  Mishandling of Exceptional Conditions

Broken Access Control bleibt unangefochten auf Platz eins. Security Misconfiguration springt von A05 auf A02, was die Daten der letzten Jahre widerspiegeln: Fehlkonfigurationen in Cloud-Diensten, IAM-Policies und Default-Settings sind das, was Pentester in der Breite am häufigsten als wirksame Einstiegsvektoren finden.

Mapping-Tabelle 2021 → 2025

2021	2025	Änderung
A01 Broken Access Control	A01 Broken Access Control	unverändert
A02 Cryptographic Failures	A04 Cryptographic Failures	Rang −2
A03 Injection	A05 Injection	Rang −2
A04 Insecure Design	A06 Insecure Design	Rang −2
A05 Security Misconfiguration	A02 Security Misconfiguration	Rang +3
A06 Vulnerable and Outdated Components	A03 Software Supply Chain Failures	umbenannt, erweitert, Rang +3
A07 Identification and Authentication Failures	A07 Authentication Failures	umbenannt
A08 Software and Data Integrity Failures	A08 Software or Data Integrity Failures	Wording-Präzisierung
A09 Security Logging and Monitoring Failures	A09 Security Logging and Alerting Failures	umbenannt
A10 Server-Side Request Forgery (SSRF)	—	als eigene Kategorie gestrichen
—	A10 Mishandling of Exceptional Conditions	neu

Software Supply Chain Failures (neu auf A03)

Die Kategorie aus 2021 hieß „Vulnerable and Outdated Components" und war im Kern eine SCA-Checkliste: bekannt verwundbare Bibliotheken finden, patchen, fertig. Die 2025er Fassung ist deutlich breiter. Laut OWASP deckt sie jetzt „breakdowns or other compromises in the process of building, distributing, or updating software" ab — also den gesamten Lieferweg inklusive Build-Pipelines, Signaturprüfung, Registry-Vertrauen und nicht gewarteter Komponenten.

Die zugeordneten CWEs spiegeln das wider: neben dem bekannten CWE-1035 (Using Components with Known Vulnerabilities) kommen CWE-1104 (Unmaintained Third Party Components), CWE-1329 (Reliance on Component That is Not Updateable) und CWE-1357 (Reliance on Insufficiently Trustworthy Component) hinzu.

Für Pentests heißt das konkret: Ein CVE-Scan der package-lock.json reicht nicht mehr, um die Kategorie abzudecken. Dazu gehören inzwischen Fragen wie: Wer kann in die Build-Pipeline hineinschreiben? Werden interne Artefakte signiert und beim Deployment verifiziert? Gibt es Abhängigkeiten auf Pakete, deren Maintainer seit Jahren inaktiv sind? Wer im Developer-Umfeld tiefer einsteigen will, findet bei der CNCF Software Supply Chain Security Paper einen guten Startpunkt.

Mishandling of Exceptional Conditions (neu auf A10)

Hinter dem sperrigen Namen steckt eine alte Bekannte: mangelhaftes Fehlerverhalten. Die Kategorie fasst 24 CWEs zusammen, die sich darum drehen, wie eine Anwendung auf unerwartete Zustände reagiert — von ausführlichen Stacktraces im HTTP-Response (CWE-209) über NULL-Pointer-Dereferenzen (CWE-476) und Fail-Open-Verhalten bei Authentifizierungschecks (CWE-636) bis zu Race-Conditions und Ressourcen-Leaks unter Last.

Das ist keine neue Klasse von Schwachstellen, aber sie hatte 2021 keinen eigenen Platz. Viele Findings, die Pentester bisher unter „Information Disclosure" oder „Insecure Design" abgelegt haben, gehören nun sauber hierher. Wer sein Finding-Template pflegt, sollte dafür eine eigene Rubrik anlegen, sonst entstehen uneindeutige Zuordnungen.

SSRF ist nicht weg, aber nicht mehr eigenständig

Server-Side Request Forgery war 2021 als A10 mit einem knappen Kommentar zu Umfragedaten ins Ranking gerutscht. In der 2025er Fassung taucht es nicht mehr als eigene Kategorie auf. SSRF ist damit nicht aus der Welt, sondern wird typischerweise unter Broken Access Control (fehlende Validierung interner Endpoints) oder Insecure Design (fehlende Trennung von internen und externen Requests) einsortiert.

Für Testpläne heißt das: SSRF bleibt selbstverständlich Teil jedes Webanwendungs-Pentests, nur die Kategorie für den Bericht ändert sich. Wer Cloud-Pentests macht, wird SSRF ohnehin im Kontext von IMDS-Zugriffen (EC2, GCE) und Metadata-Service-Escalation sehen — und das passt inhaltlich klarer zu Broken Access Control.

Stille, aber wichtige Umbenennungen

Zwei Umbenennungen wirken wie Wording-Politur, sind aber inhaltlich relevant:

A07: Authentication Failures (vorher „Identification and Authentication Failures") schärft den Fokus auf die Authentifizierung selbst. OWASP verweist in der 2025er Fassung explizit auf NIST SP 800-63B und nimmt neuere Angriffsformen wie hybride Password-Spray-Attacken explizit auf. Wer MFA-Bypass-Tests, Session-Fixation oder Credential-Stuffing im Pentest-Umfang hat, kann den Scope weitgehend übernehmen — aber die Erwartung ist jetzt, dass Tests gegen 800-63B-konforme Implementierungen gefahren werden.

A09: Security Logging and Alerting Failures (vorher „Logging and Monitoring") verschiebt den Schwerpunkt. Logs allein reichen nicht mehr. Eine Kategorie-konforme Umsetzung fordert jetzt aktives Alerting mit funktionierenden Playbooks. Für Pentests, die gegen ein SOC oder Blue Team laufen, wird die Frage relevanter, ob erzeugte Events tatsächlich in einer umsetzbaren Meldung münden — oder im Rauschen untergehen.

Konsequenzen für Pentest-Scoping und Finding-Templates

Wer Pentests nach OWASP-Kategorien strukturiert, sollte drei Dinge anpassen:

1. Finding-Template umbenennen, nicht nur die Kategorie-ID. Ein Finding, das 2023 unter „A06 Vulnerable Components" dokumentiert wurde, gehört 2025 in die breitere Klasse „Software Supply Chain Failures" — mit der Konsequenz, dass Tests zu Pipeline- und Artefaktsicherheit mit in den Scope gehören.
2. SSRF-Findings neu kategorisieren. Am saubersten unter Broken Access Control, wenn interne Ressourcen ohne Authorization-Check erreichbar waren, oder unter Insecure Design, wenn die Architektur die Trennung gar nicht vorgesehen hat.
3. Eigene Rubrik für Mishandling of Exceptional Conditions anlegen. Stacktraces in Fehlerseiten, uncaught Exceptions, Race-Conditions und Fail-Open-Logik bekommen damit einen festen Platz und verschwinden nicht mehr unter zu breiten Sammel-Kategorien.

Für Auftraggeber heißt das umgekehrt: Vor dem nächsten Pentest lohnt sich ein Blick auf die Anforderungsdokumente. Wenn dort noch „A10 SSRF" steht, ist das nicht falsch, aber nicht mehr deckungsgleich mit der aktuellen Referenz.

Abgrenzung zu den anderen OWASP-Listen

Die Top 10 ist nicht die einzige OWASP-Liste mit Pentest-Relevanz. Für Mobile-Anwendungen bleibt die OWASP Mobile Top 10 der passende Rahmen, für Container-Umgebungen die OWASP Kubernetes Top 10. Wer den breiteren Kontext der OWASP-Projekte sucht (ASVS, Testing Guide, Cheat Sheets), findet einen Einstieg in unserem Beitrag zum OWASP Framework für Webanwendungen.

Fazit

Die OWASP Top 10:2025 ist weniger Revolution als die 2021er Ausgabe, aber an den richtigen Stellen präziser: Supply-Chain-Risiken haben eine eigene, sauber geschnittene Kategorie, Fehlerbehandlung bekommt endlich einen Platz, und die Umbenennung von „Monitoring" zu „Alerting" drückt aus, was in Audits ohnehin schon gefordert wird. Für Pentest-Teams bedeutet das vor allem Fleißarbeit in Templates und Scoping-Dokumenten — und ein guter Anlass, die Findings der letzten zwei Jahre einmal durchzugehen und zu prüfen, wo sich Zuordnungen nachziehen lassen.