OWASP Top 10

Die OWASP Top 10 sind ein regelmäßig aktualisiertes Bewusstseinsdokument des Open Worldwide Application Security Project, das die zehn kritischsten Sicherheitsrisiken für Webanwendungen in Kategorien zusammenfasst und damit einen weltweit anerkannten Mindeststandard für Anwendungssicherheit setzt.

Das Open Worldwide Application Security Project — bis 2023 Open Web Application Security Project — ist eine gemeinnützige Stiftung, die frei verfügbare Standards, Werkzeuge und Dokumentation rund um Softwaresicherheit veröffentlicht. Die Top 10 sind ihr bekanntestes Erzeugnis. Sie erscheinen nicht jährlich, sondern in mehrjährigen Abständen; die Ausgabe 2025 ist die achte Auflage der Liste.

Entscheidend für das richtige Verständnis: Die OWASP Top 10 sind kein Prüfkatalog und keine Zertifizierungsnorm. Sie sind ein Awareness-Dokument. Wer eine vollständige, prüfbare Anforderungsliste braucht, greift zu den weiterführenden OWASP-Projekten, die unten abgegrenzt werden.

Wie die Liste entsteht

Die Methodik ist nach OWASPs eigener Formulierung datengestützt, aber nicht rein datengetrieben. Für die Ausgabe 2025 haben Organisationen wie Veracode, Contrast Security, Sonar, Semgrep, Bugcrowd, Probely, Orca Security, Wallarm, CryptoNet Labs, Accenture und die usd AG Testergebnisse aus über 2,8 Millionen Anwendungen beigesteuert.

Gemessen wird dabei nicht die Häufigkeit einzelner Fundstellen, sondern die Verbreitung: Welcher Anteil der getesteten Anwendungen weist mindestens eine Instanz einer bestimmten Schwachstellenklasse auf? Diese Entscheidung verhindert, dass automatisierte Scanner mit tausenden Einzelmeldungen das Bild verzerren, während manuelle Prüfer dieselbe Schwäche nur einmal notieren.

Als Vokabular dienen die Common Weakness Enumerations (CWE) von MITRE. Für die Ausgabe 2025 wurden 589 CWEs ausgewertet — gegenüber rund 400 in der Ausgabe 2021 und etwa 30 im Jahr 2017. 248 davon sind den zehn Kategorien zugeordnet, mit maximal 40 CWEs pro Kategorie. Exploitability- und Impact-Werte stammen aus CVSS-Bewertungen der in der National Vulnerability Database verzeichneten CVEs.

Acht der zehn Plätze ergeben sich aus den Daten. Zwei weitere Plätze werden über eine Community-Umfrage vergeben. Die Begründung dafür ist bemerkenswert und erklärt viel über den Charakter der Liste: Testdaten beschreiben immer die Vergangenheit. Bis eine neue Schwachstellenklasse verstanden, in Werkzeuge integriert und breit gemessen ist, vergehen Jahre. Manche Risiken lassen sich überhaupt nie zuverlässig automatisiert messen. Die Umfrage lässt Praktiker jene Risiken einbringen, die sie in der Praxis sehen, bevor sie in den Daten sichtbar werden.

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.