Die Kategorien der Ausgabe 2025
- A01:2025 – Broken Access Control: Fehlerhafte Zugriffskontrolle, weiterhin auf Platz eins. Durchschnittlich 3,73 % der getesteten Anwendungen wiesen mindestens eine der 40 CWEs dieser Kategorie auf. Server-Side Request Forgery, 2021 noch eine eigene Kategorie, wurde hier eingegliedert.
- A02:2025 – Security Misconfiguration: Fehlkonfiguration, aufgestiegen von Platz fünf. 3,00 % der Anwendungen betroffen, 16 CWEs. OWASP begründet den Anstieg damit, dass immer größere Teile des Anwendungsverhaltens über Konfiguration statt über Code gesteuert werden.
- A03:2025 – Software Supply Chain Failures: Neu. Erweitert die frühere Kategorie „Vulnerable and Outdated Components" auf das gesamte Ökosystem aus Abhängigkeiten, Build-Systemen und Distributionsinfrastruktur. In den Daten selten vertreten, aber mit den höchsten durchschnittlichen Exploit- und Impact-Werten und in der Community-Umfrage überwältigend als Top-Sorge benannt.
- A04:2025 – Cryptographic Failures: Kryptografische Fehler, von Platz zwei auf vier. 3,80 % der Anwendungen, 32 CWEs.
- A05:2025 – Injection: Von Platz drei auf fünf. 38 CWEs, darunter Cross-Site-Scripting (häufig, geringerer Einzelschaden) und SQL-Injection (seltener, hoher Schaden). Die Kategorie mit den meisten zugeordneten CVEs.
- A06:2025 – Insecure Design: Unsicheres Design, von Platz vier auf sechs. OWASP führt den Rückgang auf messbare Fortschritte bei Threat Modeling zurück.
- A07:2025 – Authentication Failures: Umbenannt von „Identification and Authentication Failures", unverändert auf Platz sieben, 36 CWEs. Der verbreitete Einsatz standardisierter Authentifizierungs-Frameworks zeigt Wirkung.
- A08:2025 – Software or Data Integrity Failures: Verletzte Integrität von Software-, Code- und Datenartefakten auf einer tieferen Ebene als A03.
- A09:2025 – Security Logging & Alerting Failures: Umbenannt von „Logging and Monitoring Failures". Die Namensänderung betont Alarmierung: Protokollierung ohne Alarmierung bringt für die Erkennung von Vorfällen kaum Nutzen.
- A10:2025 – Mishandling of Exceptional Conditions: Neu. 24 CWEs rund um mangelhafte Fehlerbehandlung, logische Fehler und Systeme, die im Ausnahmefall unsicher statt sicher reagieren.
Was sich gegenüber 2021 geändert hat
Die Ausgabe 2021 umfasste: Broken Access Control, Cryptographic Failures, Injection, Insecure Design, Security Misconfiguration, Vulnerable and Outdated Components, Identification and Authentication Failures, Software and Data Integrity Failures, Security Logging and Monitoring Failures sowie Server-Side Request Forgery.
Die Richtung ist eindeutig: weg von der einzelnen Code-Zeile, hin zu Konfiguration, Lieferkette und Betrieb. Das entspricht der Realität moderner Anwendungen, in denen der überwiegende Teil des ausgelieferten Codes aus fremden Abhängigkeiten stammt.
Abgrenzung zu anderen OWASP-Projekten
Die Top 10 werden regelmäßig mit Dokumenten verwechselt, die einen anderen Zweck erfüllen.
- OWASP ASVS (Application Security Verification Standard) ist der Prüfstandard. Er formuliert hunderte konkrete, testbare Anforderungen in gestaffelten Sicherheitsstufen. Wo die Top 10 Bewusstsein schaffen, liefert der ASVS die Abnahmekriterien. Für Verträge und Sicherheitsprüfungen ist er die belastbarere Grundlage.
- OWASP API Security Top 10 ist eine eigenständige Liste für Schnittstellen. Sie deckt Risiken ab, die bei reinen API-Backends anders wiegen als bei klassischen Weboberflächen, etwa objektbezogene Autorisierung oder fehlende Ratenbegrenzung.
- OWASP Mobile Top 10 und weitere abgeleitete Listen behandeln mobile Anwendungen und angrenzende Felder. Für Anwendungen mit Sprachmodellen existiert eine eigene Risikoliste.
- OWASP Cheat Sheet Series und der Web Security Testing Guide liefern die praktische Umsetzung: Handlungsanweisungen pro Thema und eine Testmethodik.
Eine sinnvolle Arbeitsteilung sieht so aus: Die Top 10 dienen der Sensibilisierung und als Einstiegsraster in Schulungen, der ASVS definiert die verbindlichen Anforderungen, der Testing Guide beschreibt die Prüfung.
Rolle in Ausschreibungen und Abnahmen
In Leistungsverzeichnissen und Lastenheften taucht die Formulierung „Entwicklung nach OWASP Top 10" sehr häufig auf. Sie ist gut gemeint, aber juristisch wie technisch unscharf, weil die Top 10 keine prüfbaren Anforderungen enthalten. Eine Aussage wie „die Anwendung ist OWASP-Top-10-konform" lässt sich nicht objektiv belegen.
Belastbarer sind Formulierungen, die den Prüfmaßstab benennen. Bewährt haben sich folgende Bausteine:
- Verweis auf eine konkrete ASVS-Stufe statt auf die Top 10 pauschal.
- Verpflichtung zu automatisierter Abhängigkeitsprüfung in der Build-Pipeline mit definierter Reaktionszeit für kritische Befunde.
- Nennung der Prüfmethodik, etwa nach OWASP Web Security Testing Guide, samt Abnahmezeitpunkt.
- Regelung, wer Befunde aus einem Penetrationstest behebt und in welcher Frist, mit Klassifizierung nach Schweregrad.
- Anforderung an Protokollierung und Alarmierung sicherheitsrelevanter Ereignisse — der in der Praxis am häufigsten übersehene Punkt.
Für die Beschaffungsseite ist außerdem relevant, dass die Top 10 sich auf die Anwendungsebene beschränken. Betriebssicherheit, Netzwerksegmentierung, Identitätsmanagement und organisatorische Maßnahmen fallen nicht darunter und müssen separat geregelt werden.
Relevanz für E-Commerce und B2B im Mittelstand
Onlineshops und B2B-Portale vereinen genau die Merkmale, die die Liste adressiert: personenbezogene Daten, Zahlungsvorgänge, Rabatt- und Preislogik, individuelle Berechtigungen und eine hohe Zahl fremder Erweiterungen.
Besonders greifbar ist A01, fehlerhafte Zugriffskontrolle. In einem B2B-Shop mit Firmenkonten, Unterbenutzern, kundenindividuellen Preislisten und Budgetfreigaben entscheidet die Autorisierungslogik darüber, ob ein Einkäufer die Konditionen eines anderen Unternehmens einsehen kann. Solche Fehler sind mit automatisierten Werkzeugen schwer zu finden, weil das Werkzeug die fachliche Berechtigung nicht kennt.
Ebenso praxisnah ist A03. Ein typischer Shop bringt neben dem Kern dutzende Erweiterungen von Drittanbietern mit. Jede davon ist Teil der Lieferkette, und ihre Aktualität entscheidet über die Angriffsfläche. Auch A09 hat unmittelbare wirtschaftliche Bedeutung: Ohne Alarmierung bleibt ein automatisierter Anmeldeversuch über gestohlene Zugangsdaten wochenlang unbemerkt.
Realbeispiel: Log4Shell
Die Schwachstelle CVE-2021-44228 in der weit verbreiteten Java-Protokollierungsbibliothek Apache Log4j, im Dezember 2021 veröffentlicht und als Log4Shell bekannt geworden, zeigt die Kategorie Lieferkette in Reinform. Betroffen waren nicht Anwendungen, die einen Fehler enthielten, sondern Anwendungen, die eine Bibliothek einbanden, die einen Fehler enthielt — oft unbewusst, weil Log4j als transitive Abhängigkeit über andere Komponenten hereinkam. Die entscheidende Frage in den Tagen danach war keine Sicherheitsfrage im engeren Sinne, sondern eine Inventarfrage: Wo im eigenen Portfolio steckt diese Bibliothek überhaupt? Organisationen mit vollständiger Komponenteninventur beantworteten das in Stunden, andere in Wochen. Genau diese Erfahrung steht hinter der Aufwertung der Lieferkette zur eigenständigen Kategorie A03.
Praktische Umsetzung
Die Liste entfaltet ihren Wert erst, wenn sie in den Entwicklungsprozess eingebettet wird statt als Checkliste am Projektende zu erscheinen.
- Im Design: Threat Modeling für sicherheitskritische Abläufe — Anmeldung, Bezahlung, Berechtigungsvergabe, Datenexport.
- In der Entwicklung: Statische Analyse und Abhängigkeitsprüfung als automatischer Schritt in der Pipeline, mit definierter Abbruchschwelle.
- Vor dem Release: Dynamische Prüfung der laufenden Anwendung, ergänzt um manuelle Tests der Autorisierungslogik, die Werkzeuge nicht abdecken.
- Im Betrieb: Protokollierung sicherheitsrelevanter Ereignisse mit Alarmierung und geübtem Eskalationsweg.
- Organisatorisch: Ein definierter Prozess für eingehende Schwachstellenmeldungen und regelmäßige Auffrischung des Entwicklerwissens.
Grenzen und häufige Missverständnisse
Die Top 10 sind keine vollständige Risikoliste. Sie benennen zehn Kategorien, nicht zehn Schwachstellen, und decken bewusst nur das ab, was in der Breite relevant ist. Branchenspezifische Risiken fehlen. Zudem spiegelt der datengestützte Teil nur wider, was sich automatisiert testen lässt — OWASP weist selbst darauf hin, dass gerade die Lieferketten-Kategorie in den Daten unterrepräsentiert ist.
Ein weiteres Missverständnis betrifft die Reihenfolge. Die Nummerierung ist eine Rangfolge nach Verbreitung und Auswirkung über alle ausgewerteten Anwendungen hinweg, keine Priorisierung für ein konkretes System. Für ein internes Werkzeug ohne Nutzerkonten mag A01 nachrangig sein, während A02 dominiert.
Ausblick
Die Entwicklung der letzten beiden Auflagen deutet auf eine Verlagerung hin: Klassische Implementierungsfehler verlieren relativ an Gewicht, weil Frameworks sie zunehmend von sich aus verhindern. An ihre Stelle treten Risiken, die aus Zusammensetzung und Betrieb entstehen — Lieferkette, Konfiguration, Verhalten im Ausnahmefall. Parallel wirkt die europäische Regulierung in dieselbe Richtung: Der Cyber Resilience Act verlangt für Produkte mit digitalen Elementen unter anderem eine Stückliste der enthaltenen Softwarekomponenten, was die Lieferketten-Transparenz von einer Empfehlung zu einer Pflicht macht.
Häufige Fragen
Wie oft werden die OWASP Top 10 aktualisiert?
In mehrjährigen Abständen, nicht nach festem Turnus. Auf die Ausgabe 2021 folgte die Ausgabe 2025 als achte Auflage.
Sind die OWASP Top 10 verpflichtend?
Nicht als Gesetz. Sie gelten aber als anerkannter Stand der Technik und werden in Verträgen, Sicherheitsrichtlinien und Prüfvorgaben regelmäßig referenziert — mittelbar entfalten sie dadurch erhebliche Verbindlichkeit.
Reicht ein automatisierter Scanner zur Abdeckung?
Nein. Werkzeuge finden zuverlässig, was sich ohne fachliches Verständnis erkennen lässt. Fehler in der Autorisierungslogik und unsicheres Design erfordern manuelle Prüfung und Bedrohungsmodellierung.
Was ist der Unterschied zwischen den Top 10 und dem ASVS?
Die Top 10 sind ein Bewusstseinsdokument mit zehn Risikokategorien. Der ASVS ist ein Prüfstandard mit hunderten testbaren Einzelanforderungen in gestaffelten Stufen. Für Abnahmen und Ausschreibungen ist der ASVS die geeignetere Referenz.
Gelten die Top 10 auch für Schnittstellen und mobile Apps?
Teilweise. Für diese Bereiche existieren eigene Listen — die OWASP API Security Top 10 und die OWASP Mobile Top 10 —, die die dort typischen Risiken genauer treffen.
Die vollständige Liste samt Methodik und Einzelkategorien ist frei verfügbar unter owasp.org/Top10.
