OWASP Top 10 2025: Die häufigsten Schwachstellen in Webanwendungen
Die OWASP Top 10 2025 nennt die zehn wichtigsten Risikokategorien für Webanwendungen, angeführt von fehlerhafter Zugriffskontrolle und falscher Konfiguration. Neu sind die Kategorien zu Lieferketten der Software und zum Umgang mit Ausnahmefällen.
Die Liste ist kein Prüfstandard, sondern eine Rangfolge der Fehler, die in echten Anwendungen am häufigsten und mit den schwersten Folgen auftreten. Für Geschäftsführer und IT-Verantwortliche ist sie deshalb eine brauchbare Gesprächsgrundlage: Wer eine Webanwendung betreibt oder beauftragt, kann mit ihr fragen, welche der zehn Kategorien geprüft sind und wie. Wie wir Sicherheit in Projekten verankern, beschreibt die Seite Sicherheit und Compliance.
Grundlagen
Was die OWASP Top 10 ist
Die OWASP Top 10 ist ein Dokument des Open Worldwide Application Security Project, einer gemeinnützigen Stiftung, die freie Werkzeuge und Leitfäden zur Anwendungssicherheit veröffentlicht. OWASP hat die Ausgabe 2025 im November 2025 auf der Konferenz Global AppSec in Washington vorgestellt; ein Datum für die fertige Fassung nennt owasp.org nicht. Die Vorgängerversion stammt von 2021.
Grundlage sind Testdaten aus mehr als 2,8 Millionen Anwendungen, die verschiedene Organisationen beigesteuert haben. Ausgewertet wurden 589 Schwachstellentypen nach dem CWE-Katalog, rund 400 waren es 2021. Acht Kategorien ergeben sich aus diesen Daten, zwei hat eine Umfrage unter Fachleuten bestimmt: die Lieferkette (A03) und das Protokollieren mit Alarmierung (A09). Die Begründung von OWASP: Für diese Risiken finden automatische Tests wenig, obwohl sie in der Praxis schwer wiegen.
Wichtig für die Einordnung: Die Top 10 ist ein Dokument zur Sensibilisierung. Wer prüfbare Anforderungen braucht, etwa für einen Vertrag oder ein Audit, greift zum Application Security Verification Standard (ASVS) derselben Stiftung, aktuell in Version 5.0.0 vom Mai 2025.
Überblick
Die Kategorien im Überblick
Die zehn Kategorien der Ausgabe 2025 mit den Bezeichnungen von OWASP und einer kurzen Erklärung:
A01:2025 Broken Access Control: Nutzer sehen oder ändern Daten, die ihnen nicht gehören, etwa die Rechnung eines anderen Kunden durch Ändern einer Nummer in der Adresse. Server-Side Request Forgery (SSRF) gehört seit 2025 hierher.
A02:2025 Security Misconfiguration: offene Admin-Oberflächen, Standardpasswörter, ausführliche Fehlermeldungen im Live-Betrieb, fehlende Sicherheits-Header.
A03:2025 Software Supply Chain Failures: Risiken aus Paketen, Build-Werkzeugen und Auslieferungswegen, von veralteten Bibliotheken bis zu kompromittierten Paketen.
A04:2025 Cryptographic Failures: unverschlüsselte Übertragung, schwache Verfahren, Passwörter ohne geeignetes Hashing, Schlüssel im Quellcode.
A05:2025 Injection: Eingaben werden als Befehl ausgeführt, etwa in SQL-Abfragen oder als Skript im Browser (Cross-Site-Scripting).
A06:2025 Insecure Design: Fehler im Entwurf, die keine saubere Umsetzung mehr behebt, etwa ein Gutschein, der sich beliebig oft einlösen lässt.
A07:2025 Authentication Failures: schwache Anmeldung, fehlender Schutz gegen das Durchprobieren von Passwörtern, Sitzungen, die nach dem Abmelden gültig bleiben.
A08:2025 Software or Data Integrity Failures: Updates, Daten oder serialisierte Objekte werden ohne Prüfung ihrer Herkunft übernommen.
A09:2025 Security Logging and Alerting Failures: Angriffe hinterlassen keine Spuren im Logging, oder niemand wird benachrichtigt.
A10:2025 Mishandling of Exceptional Conditions: Fehler und Sonderfälle werden falsch behandelt, das System bleibt im Zweifel offen statt geschlossen.
Änderungen
Was sich gegenüber 2021 geändert hat
Die Spitze bleibt gleich: Fehlerhafte Zugriffskontrolle ist wie 2021 auf Platz 1. Darunter hat sich mehr bewegt, als die Liste auf den ersten Blick zeigt.
Neu: A10 Mishandling of Exceptional Conditions. Die Kategorie fasst 24 Schwachstellentypen zu Fehlerbehandlung, Logikfehlern und „failing open“ zusammen, also Systemen, die bei einem Fehler den Zugang freigeben statt sperren.
Erweitert: A03 Software Supply Chain Failures. Aus „Vulnerable and Outdated Components“ (A06:2021) wird eine Kategorie für die ganze Lieferkette: Abhängigkeiten, Build-Systeme und Verteilung.
Zusammengelegt: SSRF war 2021 eine eigene Kategorie (A10:2021) und gehört seit 2025 zu A01.
Aufgestiegen: Security Misconfiguration springt von Platz 5 auf Platz 2. Anwendungen bestehen zunehmend aus Konfiguration, von Cloud-Diensten bis zu Framework-Schaltern.
Abgestiegen: Cryptographic Failures (von 2 auf 4), Injection (von 3 auf 5) und Insecure Design (von 4 auf 6). Injection ist nicht verschwunden. Frameworks wie Laravel binden aber Parameter in Datenbankabfragen und maskieren Ausgaben in Vorlagen standardmäßig, das verhindert viele klassische Fälle.
Umbenannt: A07 heißt nur noch „Authentication Failures“, A09 betont mit „Alerting“ statt „Monitoring“, dass Protokolle ohne Benachrichtigung wenig nützen.
Für Betreiber bedeutet die Verschiebung: Eine Anwendung, die vor fünf Jahren sauber programmiert wurde und seitdem keine Updates bekommen hat, ist inzwischen angreifbarer als bei der Abnahme, ohne dass jemand eine Zeile geändert hat. Außerdem entstehen viele Lücken nicht mehr im eigenen Code, sondern in Paketen, Einstellungen und im Zusammenspiel der Teile. Wie regelmäßige Updates dagegen helfen, beschreibt der Beitrag Patch-Disziplin: kleine Updates, großer Schaden.
Prüfung
Wie Sie Ihre Anwendung dagegen prüfen
Eine erste Prüfung gegen die Top 10 braucht kein großes Projekt. Viele Punkte lassen sich mit wenigen gezielten Schritten klären, bevor ein externer Pentest beauftragt wird.
Fünf Prüfschritte, die wenig Aufwand machen
Fremde Nummern ausprobieren (A01): Melden Sie sich als Nutzer A an, öffnen Sie einen eigenen Datensatz, etwa /rechnungen/1043, und ändern Sie die Zahl auf 1044. Erscheint ein Datensatz von Nutzer B, ist die Zugriffskontrolle lückenhaft. Prüfen Sie das auch für Downloads, Exporte und Schnittstellen, nicht nur für die sichtbaren Seiten. Oft ist die Liste der eigenen Datensätze korrekt gefiltert, während Einzelansicht und PDF-Download nur prüfen, ob jemand angemeldet ist, nicht, wem der Datensatz gehört.
Fehlerseite provozieren (A02, A10): Rufen Sie eine Adresse mit ungültigem Parameter auf. Zeigt die Anwendung einen Stacktrace mit Dateipfaden oder Konfigurationswerten, ist der Debug-Modus im Live-Betrieb aktiv. In Laravel steuert das ein Eintrag in der Umgebungsdatei, die Dokumentation verlangt ihn im Live-Betrieb ausgeschaltet.
Abhängigkeiten prüfen (A03): Der Paketmanager Composer hat einen eigenen Prüfbefehl, der die PHP-Pakete eines Projekts mit bekannten Sicherheitsmeldungen abgleicht, npm bietet dasselbe für JavaScript-Pakete. Beide Prüfungen laufen in Sekunden und gehören in jede Auslieferung. Achten Sie außerdem darauf, dass die Sperrdatei von Composer (composer.lock) im Repository liegt. Ohne sie installiert der Server bei jeder Auslieferung die gerade neuesten Paketversionen, und niemand weiß genau, welcher Code live läuft.
Anmeldung testen (A07): Wie oft lässt sich ein falsches Passwort eingeben, bevor die Anwendung bremst? Bleibt eine Sitzung nach dem Abmelden in einem zweiten Tab gültig? Passkeys schließen ganze Fehlerklassen aus, siehe Passkeys in Webanwendungen.
Protokolle lesen (A09): Lassen Sie fünf fehlgeschlagene Anmeldungen auslösen und fragen Sie, wo sie auftauchen und wer davon erfährt. Wenn die Antwort „in einer Logdatei auf dem Server“ lautet, fehlt die Alarmierung. Wie viel Gewicht Protokolle in regulierten Umgebungen haben, zeigt ein FinTech-Backend für eine Versicherungsgruppe, an dem wir über viele Monate mit wechselndem Umfang mitgearbeitet haben: Ein nachvollziehbarer Audit-Trail für Verträge, Bewegungen und Audit-Events war dort Teil des Auftrags, nicht ein Zusatz.
Die übrigen Kategorien
Auch für die vier Kategorien ohne eigenen Schnelltest gibt es eine Frage, mit der Sie anfangen können:
Cryptographic Failures (A04): Wie werden Passwörter gespeichert? Laravel nutzt standardmäßig bcrypt, auf Wunsch Argon2. Werden Passwörter, Schlüssel für Schnittstellen oder Kundendaten irgendwo im Klartext abgelegt, etwa in Exporten oder Logdateien?
Injection (A05): Gibt es Stellen, an denen SQL oder HTML von Hand aus Eingaben zusammengesetzt wird, statt über Query Builder und Vorlagen? Diese Stellen sind schnell gezählt und sollten einzeln geprüft werden.
Insecure Design (A06): Welche Geschäftsregel würde ein findiger Nutzer ausnutzen, etwa Rabatte, Kontingente oder Freigaben? Die Antwort liefert ein Gespräch mit den Fachabteilungen.
Software or Data Integrity Failures (A08): Woher kommen Updates, Importe und Webhooks, und prüft die Anwendung ihre Herkunft, etwa über Signaturen bei eingehenden Webhooks?
Was eine gründliche Prüfung zusätzlich braucht
Die fünf Schritte zeigen grobe Lücken. Entwurfsfehler (A06) und Fehlerbehandlung (A10) finden Sie nur im Code: Was passiert, wenn der Zahlungsdienst nicht antwortet? Gilt die Bestellung dann als bezahlt? Solche Fragen klärt ein Code-Review entlang der Geschäftsprozesse, idealerweise mit den ASVS-Anforderungen als Checkliste. Wer unter NIS2 fällt, muss solche Prüfungen ohnehin nachweisen können, siehe NIS2 im Mittelstand.
Die fünf Prüfschritte schafft ein technisch versierter Mitarbeiter in etwa einem halben Tag. Für ein Code-Review einer mittelgroßen Anwendung gegen alle zehn Kategorien rechnen wir mit 3 bis 5 Personentagen, abhängig von der Zahl der Rollen und Schnittstellen. Wer zwei Mandanten oder Kundengruppen trennt, findet die passende Prüfung im Beitrag zur Mandantenfähigkeit.
Zur Einordnung
Häufige Fragen
-
Nein. OWASP beschreibt die Liste selbst als Dokument zur Sensibilisierung, nicht als prüfbaren Standard. Für Verträge, Ausschreibungen und Audits eignet sich der Application Security Verification Standard (ASVS), der Anforderungen in Stufen gliedert. Viele Prüfberichte nutzen die Top-10-Kategorien trotzdem als Gliederung, weil Auftraggeber sie kennen.
-
Automatische Paketprüfungen gehören in jede Auslieferung und laufen damit mehrmals im Monat. Ein manueller Durchgang durch die Kategorien ist nach größeren Funktionen sinnvoll, etwa einem neuen Rollenmodell oder einer neuen Schnittstelle. Für Anwendungen mit Kundendaten ist zusätzlich ein externer Pentest vor dem Start und nach größeren Umbauten sinnvoll, weil ein Außenstehender die Anwendung ohne die Annahmen des eigenen Teams angreift.
Ihre Anwendung gegen die Top 10 prüfen lassen
Mit Pentests, IT-Audits und Sicherheitsanalysen finden wir Schwachstellen, bevor andere sie ausnutzen, und schreiben die Funde so auf, dass Ihr Team sie beheben kann.
Nachweise
Quellen und Stand
Stand: 12.10.2026. Kategorien, Bezeichnungen, Datengrundlage und die Zahl der Schwachstellentypen in A10 laut owasp.org. Ein genaues Veröffentlichungsdatum der Ausgabe 2025 nennt owasp.org nicht.
OWASP Top 10:2025, Einführung mit den Änderungen gegenüber 2021
OWASP Top 10:2025, A10 Mishandling of Exceptional Conditions (24 CWEs)
Weiterlesen: Spam über Kontaktformulare mit Rate-Limits gegen automatisierte Anfragen.
Artikel teilen