Wissen · Leitfaden Anwendungssicherheit

OWASP Top 10 erklärt: Was die Liste leistet und was du fragen solltest

Die OWASP Top 10 ist eine nach Risiko geordnete Liste der kritischsten Sicherheitsprobleme von Webanwendungen. Aktuell ist die Ausgabe 2025, die die Liste von 2021 abgelöst hat. Sie ist eine gute gemeinsame Sprache für Einkauf und Entwicklung, aber ein Dokument zur Sensibilisierung und kein vollständiger Sicherheitsstandard.

Aktualisiert: 6. November 2026

Was die OWASP Top 10 ist und welche Ausgabe gilt

OWASP, das Open Worldwide Application Security Project, ist eine gemeinnützige Community, die kostenlos Sicherheitsmaterial veröffentlicht. Die Top 10 nennt die zehn Risikokategorien, die für Webanwendungen am wichtigsten sind. Auf owasp.org ist heute die Ausgabe 2025 veröffentlicht; es ist die achte Auflage, und sie ersetzt die Liste von 2021. Laut OWASP basiert sie auf Daten von mehr als 2,8 Millionen Anwendungen und 589 Schwachstellentypen (CWEs), zwei Kategorien kamen durch eine Umfrage in der Community hinzu.

Jede Kategorie bündelt viele einzelne Schwachstellen. Deshalb eignet sich die Liste gut für Verträge und Berichte: Wenn ein Test 'Injection' oder 'Broken Access Control' abdeckt, weiß jeder ungefähr, was gemeint ist.

Die zehn Kategorien in einfachen Worten

Hier die Kategorien 2025 in der Rangfolge, jeweils mit einem typischen Beispiel. Die Gegenmaßnahmen folgen im nächsten Abschnitt.

• A01 Broken Access Control (fehlerhafte Zugriffskontrolle): Nutzer sehen oder ändern, was sie nicht dürfen. Beispiel: Wer in der Adresszeile eine Kontonummer ändert, sieht die Daten eines anderen Kunden. Server-Side Request Forgery gehört jetzt zu dieser Kategorie.
• A02 Security Misconfiguration (Fehlkonfiguration): Systeme sind unsicher eingerichtet. Beispiel: eine Admin-Oberfläche mit Standardpasswort oder ein Cloud-Speicher, der offen im Internet steht. Die Kategorie ist von Platz fünf auf Platz zwei gestiegen.
• A03 Software Supply Chain Failures (Fehler in der Software-Lieferkette): Build-, Update- oder Abhängigkeitskette ist fehlerhaft oder kompromittiert. Beispiel: Eine bösartige Paketversion wird automatisch eingebunden. Die Kategorie erweitert die frühere Kategorie 'anfällige und veraltete Komponenten'.
• A04 Cryptographic Failures (kryptografische Fehler): Sensible Daten sind nicht ausreichend geschützt. Beispiel: personenbezogene Daten werden ohne starke Verschlüsselung übertragen oder gespeichert.
• A05 Injection: Nicht vertrauenswürdige Eingaben werden als Befehl oder Abfrage ausgeführt. Beispiel: SQL-Injection über ein Suchfeld oder Cross-Site-Scripting.
• A06 Insecure Design (unsicherer Entwurf): Der Fehler steckt im Konzept, nicht im Code. Beispiel: ein Passwort-Reset, der sich missbrauchen lässt, egal wie sauber er programmiert ist.
• A07 Authentication Failures (Fehler bei der Authentifizierung): Anmeldung und Sitzungen lassen sich umgehen. Beispiel: kein Schutz gegen Passwort-Raten oder Sitzungen, die nie ablaufen.
• A08 Software or Data Integrity Failures (Integritätsfehler): Code oder Daten werden ungeprüft vertraut. Beispiel: ein Update-Mechanismus, der Signaturen nicht prüft.
• A09 Security Logging and Alerting Failures (Protokollierung und Alarmierung): Angriffe bleiben unbemerkt, weil Ereignisse nicht protokolliert werden oder niemand alarmiert wird.
• A10 Mishandling of Exceptional Conditions (falscher Umgang mit Ausnahmesituationen): die neue Kategorie. Die Software versagt bei ungewöhnlichen Situationen. Beispiel: ausführliche Datenbankfehler, die Angreifern helfen, oder eine halbfertige Transaktion, die nicht zurückgerollt wird.

So beugst du den größten Risiken vor

OWASP gibt zu jeder Kategorie konkrete Hinweise. Einige Muster wiederholen sich. Bei der Zugriffskontrolle gilt: Regeln auf dem Server durchsetzen, standardmäßig verbieten, prüfen, ob ein Datensatz dem Nutzer gehört, und Fehlversuche protokollieren. Bei Fehlkonfiguration helfen ein automatisierter, wiederholbarer Härtungsprozess, das Entfernen ungenutzter Funktionen und getrennte Zugangsdaten je Umgebung.

Gegen Lieferkettenrisiken hilft eine Software-Stückliste (SBOM), die auch indirekte Abhängigkeiten enthält, dazu laufende Scans der Komponenten, vertrauenswürdige Quellen, signierte Pakete und eine Build-Pipeline, die so gut geschützt ist wie die Produktion. Bei Ausnahmesituationen gilt: Fehler dort behandeln, wo sie entstehen, Nutzern nur harmlose Meldungen zeigen, unvollständige Transaktionen komplett zurückrollen und missbräuchliches Verhalten begrenzen.

Für die übrigen Kategorien greifen die bekannten Maßnahmen: moderne Verschlüsselung mit sauberem Schlüsselmanagement, parametrisierte Abfragen und Ausgabekodierung gegen Injection, Bedrohungsmodellierung im Entwurf, Multi-Faktor-Authentifizierung, signierte Updates sowie zentrale Protokollierung mit Alarmen, die jemand tatsächlich liest.

Warum die Top 10 kein Standard ist

OWASP beschreibt die Top 10 in erster Linie als Dokument zur Sensibilisierung. Viele Unternehmen behandeln sie trotzdem wie einen Branchenstandard, doch OWASP selbst nennt sie ein absolutes Minimum und einen Ausgangspunkt. Sie ordnet Risiken, enthält aber keine prüfbaren Anforderungen.

Für Anforderungen verweist OWASP auf den Application Security Verification Standard (ASVS). Aktuell ist Version 5.0.0, veröffentlicht am 30. Mai 2025. Der ASVS ist ein Katalog von Sicherheitsanforderungen für Entwurf, Entwicklung und Test von Webanwendungen und Webdiensten; als Einsatzzweck nennt OWASP auch Beschaffungsverträge. Wer Software kauft oder beauftragt, formuliert mit 'erfüllt ASVS auf einem festgelegten Level' deutlich präziser als mit 'ist sicher gegen die OWASP Top 10'.

So testest du gegen die Top 10

Keine einzelne Methode deckt alle zehn Kategorien ab. Statische Analyse (SAST) liest den Quellcode und findet viele Injection- und Konfigurationsfehler früh, kann aber nicht beurteilen, ob die richtigen Ereignisse protokolliert werden. Dynamische Tests (DAST) greifen die laufende Anwendung von außen an und entdecken offene Fehlermeldungen, fehlende Header und manche Zugriffsprobleme. Die Analyse von Softwarekomponenten prüft Abhängigkeiten auf bekannte Schwachstellen und unterstützt die Lieferkettenkategorie.

Ein manueller Penetrationstest findet fehlerhafte Zugriffskontrolle und Missbrauch der Geschäftslogik, weil ein Mensch verstehen muss, was jede Rolle tun darf. Unsicheren Entwurf kann man kaum testen; OWASP merkt an, dass er außerhalb der meisten Testformen liegt. Dafür braucht es Design-Reviews und Bedrohungsmodellierung. OWASP empfiehlt außerdem mindestens jährliche Penetrationstests, abhängig vom nötigen Sicherheitsniveau.

Sieh Scanner als laufendes Sicherheitsnetz und den Pentest als regelmäßige Tiefenprüfung. Beides ersetzt keine sichere Entwicklung.

Verwandte OWASP-Listen

Zwei weitere Listen werden oft mit der Web-Top-10 verwechselt. Die OWASP API Security Top 10 widmet sich Schnittstellen; die aktuelle Ausgabe auf der Projektseite ist die von 2023, mit Einträgen wie fehlerhafter Autorisierung auf Objektebene und unbegrenztem Ressourcenverbrauch. Die OWASP Top 10 for LLM Applications behandelt KI-spezifische Risiken; aktuell ist die Ausgabe 2025 mit Punkten wie Prompt Injection, Offenlegung sensibler Informationen und übermäßiger Handlungsfreiheit (Excessive Agency). Wenn dein Produkt APIs anbietet oder ein Sprachmodell einbindet, frag auch nach diesen Listen.

Was du einen Dienstleister fragen solltest

Ob du Entwickler, ein Pentest-Team oder einen Managed-Service für Schwachstellen beauftragst: Diese Fragen trennen Substanz von Schlagworten.

• Gegen welche Ausgabe der OWASP Top 10 und welche ASVS-Version samt Level arbeitet ihr?
• Welche Kategorien prüft ihr manuell, welche nur mit Werkzeugen?
• Wie testet ihr die Zugriffskontrolle für verschiedene Benutzerrollen?
• Liefert ihr eine SBOM und prüft ihr Abhängigkeiten und die Build-Pipeline?
• Ordnet der Bericht jeden Befund einer Kategorie zu und enthält er nachvollziehbare Schritte und eine Empfehlung zur Behebung?
• Ist ein Nachtest nach der Behebung enthalten?
• Wie laufen Design-Reviews oder Bedrohungsmodellierung, bevor Code entsteht?