Leitfaden

OWASP Top 10 2025: alle zehn Kategorien erklärt

Von Lucas Weber, CyberSec42 · Stand 28.10.2026

Die OWASP Top 10 2025 ist die aktuelle Fassung der bekanntesten Liste der kritischsten Sicherheitsrisiken für Web-Anwendungen. Sie reicht von A01 Broken Access Control bis A10 Mishandling of Exceptional Conditions und ersetzt die Fassung von 2021. Neu sind zwei Kategorien, Software Supply Chain Failures und Mishandling of Exceptional Conditions, außerdem ist Server-Side Request Forgery in Broken Access Control aufgegangen.

Stand der Liste: final, veröffentlicht als Release Candidate am 06.11.2025

OWASP (Open Worldwide Application Security Project) hat die Top 10 2025 am 06.11.2025 als Release Candidate vorgestellt. Dieses Datum steht im Hinweis, den das Projekt bis Ende 2025 in seiner Einleitung führte. Am 24.12.2025 wurde der Release-Candidate-Hinweis im offiziellen GitHub-Repository entfernt. Die Projektseite nennt heute die Top 10 2025 als „die aktuellste veröffentlichte Version“. Ein eigenes Datum für die finale Fassung nennt OWASP dort nicht (Stand: 28.10.2026).

Zwischen Release Candidate und finaler Fassung hat sich ein Name geändert: A09 hieß im Entwurf „Logging & Alerting Failures“ und wurde im Dezember 2025 in „Security Logging & Alerting Failures“ umbenannt. Wer mit Unterlagen aus dem November 2025 arbeitet, findet dort deshalb gelegentlich den alten Namen.

Zur Methodik schreibt OWASP: Acht der zehn Kategorien stammen aus Testdaten, die Firmen und Projekte beigesteuert haben, nach eigener Angabe zu mehr als 2,8 Millionen Anwendungen. Zwei Kategorien kommen aus einer Umfrage unter Fachleuten, weil sich manche Risiken in automatisierten Tests kaum zeigen. Die Kategorien fassen jeweils mehrere CWE-Einträge zusammen, also Schwachstellentypen aus dem Katalog von MITRE. OWASP ordnet sie bewusst nach Ursache statt nach Symptom.

Die zehn Kategorien im Überblick

Die deutschen Bezeichnungen stammen aus der offiziellen deutschen Übersetzung der OWASP Top 10:2025, die laut Versionsverlauf des Repositorys im September 2026 hinzukam. In Berichten und Werkzeugen sind die englischen Namen üblich, deshalb stehen beide hier.

Die Prüfhinweise unter jeder Kategorie gelten für Systeme, die Ihnen gehören oder für die Sie eine schriftliche Erlaubnis haben. Prüfungen an fremden Systemen ohne Auftrag sind nicht zulässig.

A01:2025 Broken Access Control (Mangelhafte Zugriffskontrolle)

Worum es geht. Zugriffskontrolle legt fest, wer welche Daten sehen und welche Funktionen nutzen darf. Fehlt sie oder lässt sie sich umgehen, sieht ein Nutzer fremde Datensätze, ändert sie oder erreicht Verwaltungsfunktionen. Neu in dieser Kategorie ist Server-Side Request Forgery (SSRF): Die Anwendung lässt sich dazu bringen, in ihrem Namen Anfragen an interne Systeme zu stellen. 2021 war SSRF noch eine eigene Kategorie (A10:2021).

Beispiel. Eine Rechnung liegt unter /api/rechnungen/1043. Ein angemeldeter Kunde ändert die Zahl auf 1044 und erhält die Rechnung eines anderen Kunden. OWASP nennt das „insecure direct object reference“.

So prüfen Sie. Mit zwei Testkonten derselben Rolle und einem Konto mit weniger Rechten: Kennungen aus Konto A in Anfragen von Konto B einsetzen, Verwaltungs-URLs als normaler Nutzer und ohne Anmeldung aufrufen, neben GET auch POST, PUT und DELETE probieren. Für SSRF jede Funktion suchen, die eine URL annimmt, etwa Bildimport oder Webhook, und prüfen, ob sie interne Adressen erreicht. Automatische Scanner finden diese Fehler selten, weil sie nicht wissen, welche Daten wem gehören.

A02:2025 Security Misconfiguration (Sicherheitsrelevante Fehlkonfiguration)

Worum es geht. Ein System ist unsicher eingestellt: Standardkonten sind aktiv, Fehlerseiten zeigen interne Details, unnötige Dienste laufen, Sicherheits-Header fehlen. Auch XML External Entities (XXE) ordnet OWASP hier ein. Die Kategorie ist von Platz 5 auf Platz 2 gestiegen. OWASP begründet das damit, dass immer mehr Verhalten einer Anwendung über Konfiguration gesteuert wird.

Beispiel. Ein Cloud-Speicher mit Kundendokumenten ist öffentlich lesbar, oder ein Framework läuft im Debug-Modus und gibt bei Fehlern den vollständigen Stacktrace samt Pfaden aus.

So prüfen Sie. Die ausgelieferten Antwort-Header Ihrer Anwendung lesen. So sieht das an unserer eigenen Website aus, gemessen am 28.10.2026 per GET:

$ curl -s -D - -o /dev/null https://www.cybersec42.com/
strict-transport-security: max-age=63072000; includeSubDomains; preload
content-security-policy: default-src 'self'; script-src 'self' 'sha256-…'; …
x-content-type-options: nosniff
x-frame-options: DENY
referrer-policy: strict-origin-when-cross-origin
permissions-policy: geolocation=(), microphone=(), camera=(), interest-cohort=()

Fehlt einer dieser Header bei Ihnen, ist das ein Hinweis, kein Beweis für eine Lücke. Weitere Prüfpunkte: Standardpasswörter, offene Verwaltungsoberflächen, Verzeichnislisten, ausführliche Fehlermeldungen und die Freigaben von Speichern und Datenbanken in der Cloud-Konsole.

A03:2025 Software Supply Chain Failures (Schwachstellen in der Software-Lieferkette)

Worum es geht. Ihre Anwendung besteht zum großen Teil aus fremdem Code: Bibliotheken, Container-Images, Build-Werkzeuge, Erweiterungen. Diese Kategorie erweitert „Vulnerable and Outdated Components“ von 2021 um alles, was beim Bauen, Verteilen und Aktualisieren von Software schiefgehen kann, bis zur CI/CD-Pipeline. Laut OWASP kommt die Kategorie selten in den Testdaten vor, wurde in der Umfrage aber mit großem Abstand als wichtiges Risiko genannt. OWASP vermutet, dass sie sich bisher schlecht testen lässt.

Beispiel. Ein Paket aus der öffentlichen Registry wird mit Schadcode neu veröffentlicht, und der nächste Build übernimmt es ungeprüft. Oder eine bekannte Lücke in einer eingebundenen Bibliothek bleibt monatelang ungepatcht, weil niemand weiß, dass sie verwendet wird.

So prüfen Sie. Eine Stückliste der Komponenten (SBOM) erzeugen, auch für indirekte Abhängigkeiten, und gegen bekannte Schwachstellen abgleichen, etwa mit npm audit, pip-audit oder OWASP Dependency-Check. Versionen fest sperren (Lockfile). In der Pipeline prüfen: Wer darf Code bis in die Produktion bringen, ohne dass ein zweiter Mensch zustimmt? Welche Geheimnisse sieht der Build?

A04:2025 Cryptographic Failures (Fehlerhafter Einsatz von Kryptografie)

Worum es geht. Schützenswerte Daten werden unverschlüsselt übertragen oder gespeichert, mit veralteten Verfahren verschlüsselt oder mit schlecht verwalteten Schlüsseln. OWASP nennt unter anderem veraltete Hashfunktionen wie MD5 oder SHA1, wiederverwendete Schlüssel, Schlüssel im Quellcode und fehlende Prüfung von Zertifikaten.

Beispiel. Passwörter liegen als einfacher SHA1-Hash in der Datenbank. Nach einem Datenabfluss lassen sie sich in großer Zahl zurückrechnen.

So prüfen Sie. TLS-Konfiguration mit einem Werkzeug wie testssl.sh gegen den eigenen Server prüfen. Im Code und in der Versionsverwaltung nach Schlüsseln suchen, etwa mit gitleaks. Klären, mit welchem Verfahren Passwörter gespeichert werden: Es sollte ein dafür gebautes Verfahren wie Argon2, scrypt oder bcrypt sein, kein allgemeiner Hash.

A05:2025 Injection

Worum es geht. Eingaben von außen gelangen ungefiltert an einen Interpreter, etwa die Datenbank, die Kommandozeile oder den Browser, und werden dort als Befehl ausgeführt. Dazu gehören SQL-Injection und Cross-Site Scripting (XSS). OWASP beschreibt XSS als häufig mit geringerer Wirkung, SQL-Injection als seltener mit hoher Wirkung. Die Kategorie fällt von Platz 3 auf Platz 5, bleibt aber eine der am häufigsten getesteten.

Beispiel. Ein Suchfeld setzt die Eingabe direkt in eine SQL-Abfrage ein. Ein Apostroph in der Eingabe erzeugt einen Datenbankfehler, eine gezielte Eingabe liest andere Tabellen aus.

So prüfen Sie. Im Code nach zusammengesetzten Abfragen und Befehlen suchen; sicher sind parametrisierte Abfragen. Jede Eingabe testen, nicht nur Formularfelder: URL-Parameter, Header, Cookies, JSON. Statische Codeanalyse (SAST) und dynamische Scanner (DAST) in der Pipeline finden einen Teil dieser Fehler zuverlässig. Prompt Injection bei Sprachmodellen behandelt OWASP ausdrücklich in einer eigenen Liste, siehe Abgrenzung.

A06:2025 Insecure Design (Unsicheres Design)

Worum es geht. Die Schwäche liegt im Entwurf, nicht in der Umsetzung. Auch fehlerfreier Code hilft nicht, wenn die nötige Kontrolle nie vorgesehen war. OWASP unterscheidet bewusst zwischen unsicherem Design und unsicherer Implementierung, weil Ursache und Behebung verschieden sind. Die Kategorie gibt es seit 2021; sie rutscht von Platz 4 auf Platz 6.

Beispiel. Ein Gutscheincode lässt sich beliebig oft einlösen, weil im Ablauf niemand festgelegt hat, dass er nur einmal gelten darf. Oder ein Passwort-Reset fragt Sicherheitsfragen ab, deren Antworten in sozialen Netzwerken stehen.

So prüfen Sie. Für sicherheitsrelevante Abläufe wie Bezahlen, Registrieren oder Rechte vergeben ein kurzes Bedrohungsmodell erstellen: Was darf nicht passieren, und was hindert einen Angreifer daran? OWASP schreibt selbst, dass diese Kategorie mit den meisten Testformen nicht abgedeckt wird. Hier hilft Geschäftslogik-Prüfung von Hand.

A07:2025 Authentication Failures (Fehlerhafte Authentifizierung)

Worum es geht. Die Anwendung hält jemanden für einen berechtigten Nutzer, der es nicht ist. Ursachen sind etwa fehlender Schutz gegen automatisiertes Durchprobieren von Passwörtern, schwache Passwortregeln, unsichere Passwort-Zurücksetzung, fehlende Mehr-Faktor-Anmeldung oder Sitzungen, die nach dem Abmelden gültig bleiben. Der Name wurde verkürzt; 2021 hieß die Kategorie „Identification and Authentication Failures“.

Beispiel. Ein Angreifer probiert Zugangsdaten aus fremden Datenlecks automatisiert am Login aus (Credential Stuffing). Ohne Begrenzung der Versuche gelingen einige Anmeldungen.

So prüfen Sie. Viele Fehlversuche hintereinander auslösen und beobachten, ob die Anwendung bremst oder sperrt. Prüfen, ob die Sitzungskennung nach dem Login wechselt und nach dem Abmelden ungültig ist. Den Ablauf „Passwort vergessen“ Schritt für Schritt durchgehen. Bei Tokens wie JWT prüfen, ob Ablaufzeit, Aussteller und Zielgruppe geprüft werden.

A08:2025 Software or Data Integrity Failures (Fehler bei der Software- oder Datenintegrität)

Worum es geht. Code oder Daten werden als vertrauenswürdig behandelt, ohne dass ihre Herkunft oder Unverändertheit geprüft wird. OWASP grenzt die Kategorie zu A03 so ab: Sie liegt eine Ebene tiefer, bei einzelnen Artefakten, Daten und Vertrauensgrenzen. Dazu zählen unsichere Deserialisierung, Updates ohne Signaturprüfung und Skripte von fremden Servern ohne Integritätsprüfung.

Beispiel. Eine Seite bindet ein Skript von einem fremden CDN ohne Subresource Integrity ein. Wird die Datei dort verändert, läuft der geänderte Code bei allen Besuchern.

So prüfen Sie. Im ausgelieferten HTML alle externen Skripte suchen und prüfen, ob sie ein integrity-Attribut haben. Im Code nach Deserialisierung von Daten suchen, die von außen kommen, etwa Cookies oder Uploads. Prüfen, ob Updates und Build-Artefakte signiert und vor der Verwendung geprüft werden.

A09:2025 Security Logging & Alerting Failures (Unzureichendes Sicherheitslogging und Alarmierung)

Worum es geht. Angriffe hinterlassen keine Spuren oder die Spuren lösen keine Reaktion aus. Der Name betont jetzt das Alarmieren statt nur das Überwachen. OWASP schreibt dazu sinngemäß: Gute Protokolle ohne Alarm sind für das Erkennen von Vorfällen wenig wert. Die Kategorie stammt, wie A03, aus der Umfrage, weil sie in Testdaten kaum sichtbar wird.

Beispiel. Ein Angreifer probiert über Tage tausende Passwörter aus. Die Fehlversuche werden nicht protokolliert, oder sie stehen im Protokoll, aber niemand bekommt eine Meldung.

So prüfen Sie. Prüfen, ob fehlgeschlagene Anmeldungen, Rechteänderungen und wichtige Transaktionen protokolliert werden, und ob dabei keine Passwörter oder Gesundheitsdaten im Protokoll landen. Dann gezielt einen Alarm auslösen: Kommt er an, und weiß jemand, was zu tun ist? OWASP nennt als Warnzeichen, wenn ein Penetrationstest oder ein DAST-Scan keinen Alarm auslöst.

A10:2025 Mishandling of Exceptional Conditions (Fehlerhafte Behandlung von Ausnahmezuständen)

Worum es geht. Diese Kategorie ist neu. Sie umfasst Fehler im Umgang mit ungewöhnlichen Situationen: fehlende oder unvollständige Fehlerbehandlung, Logikfehler, Wettlaufsituationen (Race Conditions) und vor allem Systeme, die bei einem Fehler offen statt geschlossen bleiben („failing open“). OWASP beschreibt drei Versäumnisse: Die Anwendung verhindert die Ausnahmesituation nicht, erkennt sie nicht oder reagiert falsch darauf.

Beispiel. Ein Beispiel aus der OWASP-Beschreibung: Eine Überweisung belastet erst das eine Konto, schreibt dann dem anderen gut und protokolliert zuletzt. Bricht der Ablauf in der Mitte ab und wird nicht vollständig zurückgerollt, entsteht ein inkonsistenter Zustand, den ein Angreifer ausnutzen kann.

So prüfen Sie. Gezielt Fehler erzeugen: unerwartete Datentypen, leere oder sehr große Werte, abgebrochene Verbindungen, parallele Anfragen auf denselben Vorgang. Danach prüfen, ob der Zustand konsistent ist, ob die Fehlermeldung interne Details zeigt und ob eine fehlgeschlagene Prüfung den Zugriff verweigert statt ihn zu erlauben.

Was hat sich gegenüber 2021 geändert

OWASP fasst die Änderungen als zwei neue Kategorien und eine Zusammenlegung zusammen. Dazu kommen Verschiebungen in der Reihenfolge und zwei Umbenennungen.

Praktisch heißt das: Wer seine Prüfungen bisher an der Fassung 2021 ausgerichtet hat, sollte vor allem drei Lücken schließen. Lieferkette und Build-Pipeline gehören jetzt ausdrücklich dazu, Fehlerbehandlung wird eigenständig geprüft, und SSRF-Tests laufen unter Zugriffskontrolle weiter, statt wegzufallen.

Abgrenzung: Web-Liste, KI-Listen und API-Liste

Unter dem Namen „OWASP Top 10“ gibt es inzwischen mehrere Listen. Dieser Artikel behandelt die klassische Liste für Web-Anwendungen. Für Anwendungen mit Sprachmodellen gilt die OWASP Top 10 für LLM-Anwendungen, für autonome KI-Agenten die OWASP Top 10 für Agentic AI und für Server nach dem Model Context Protocol die OWASP MCP Top 10. Schnittstellen haben mit der OWASP API Security Top 10 eine eigene Liste, die unsere API-Pentest-Checkliste Schritt für Schritt durchgeht.

Die Listen ergänzen sich. Ein Chatbot in Ihrer Web-Anwendung hat die Risiken der Web-Liste, etwa fehlerhafte Zugriffskontrolle, und zusätzlich die der LLM-Liste, etwa Prompt Injection.

Was die Liste nicht ist

OWASP bezeichnet die Top 10 selbst als Dokument zur Sensibilisierung („awareness document“). Sie ist keine vollständige Liste, sondern ein Einstieg. Daraus folgen drei Dinge, die bei der Arbeit mit der Liste oft übersehen werden.

• Kein Prüfstandard. Wer die Top 10 als Standard für Code oder Tests nutzt, hat laut OWASP „das absolute Minimum“. Die Liste beschreibt Risiken, nicht prüfbare Anforderungen. Für prüfbare Anforderungen empfiehlt OWASP den Application Security Verification Standard (ASVS). Die aktuelle stabile Fassung ist ASVS 5.0.0 vom 30.05.2025.
• Keine vollständige Abdeckung durch Werkzeuge. OWASP schreibt ausdrücklich, dass Werkzeuge die Top 10 nicht vollständig erkennen, testen oder abwehren können, und rät von Behauptungen einer vollständigen Abdeckung ab. Insecure Design oder wirksames Alarmieren lassen sich mit einem Scanner nicht feststellen.
• Keine Rangliste Ihrer Risiken. Die Reihenfolge beruht auf Daten über sehr viele Anwendungen und auf einer Umfrage. Für Ihre Anwendung kann A10 wichtiger sein als A01. Welche Risiken für Sie zählen, ergibt sich aus Ihren Daten, Nutzern und Abläufen.

Für die Testmethode selbst gibt es den OWASP Web Security Testing Guide (WSTG). Die drei Dokumente teilen sich die Arbeit: Die Top 10 sagt, worauf man achten sollte, der ASVS, was erfüllt sein muss, der WSTG, wie man es prüft.

Die Top 10 im Penetrationstest

In einem Penetrationstest für eine Web-Anwendung dient die Top 10 als gemeinsame Sprache. Befunde lassen sich einer Kategorie zuordnen, und Geschäftsführung und Entwicklung verstehen schnell, um welche Art von Problem es geht. Als Prüfumfang reicht sie nicht. Die folgenreichsten Befunde liegen häufig in Bereichen, die ein Scanner nicht beurteilen kann: Zugriffskontrolle zwischen Mandanten (A01), Geschäftslogik (A06) und Fehlerzustände (A10). Diese prüft man mit mehreren Testkonten und von Hand.

Ein belastbarer Bericht ordnet deshalb jeden Befund einer Kategorie zu, belegt ihn mit einem nachvollziehbaren Nachweis und sagt offen, welche Kategorien im vereinbarten Umfang nicht oder nur teilweise geprüft wurden, etwa A09, wenn kein Zugriff auf das Monitoring bestand. Wie ein solcher Test abläuft und wovon der Aufwand abhängt, beschreibt der Artikel Penetrationstest: Ablauf, Dauer und Kosten.

Häufige Fragen

Weiterlesen

• API-Pentest: Checkliste nach OWASP API Top 10
• Penetrationstest: Ablauf, Dauer und Kosten
• OWASP LLM Top 10 2026, praktisch erklärt
• Leistung: Penetrationstest

Quellen

• OWASP Top 10:2025
• OWASP Top 10:2025, deutsche Übersetzung
• OWASP Top 10:2025, Introduction (Änderungen und Methodik)
• OWASP Top 10:2025, Establishing a Modern Application Security Program (Nutzung als Standard)
• OWASP Top 10:2025, A01 Broken Access Control
• OWASP Top 10:2025, A10 Mishandling of Exceptional Conditions
• OWASP Top 10, GitHub-Repository (Versionsverlauf, Release-Candidate-Hinweis)
• OWASP Top Ten, Projektseite
• OWASP Top 10:2021
• OWASP Application Security Verification Standard (ASVS)
• OWASP Web Security Testing Guide (WSTG)