OWASP Top Ten 2025

Das Open Worldwide Application Security Project (OWASP) veröffentlichte am 6. November den Release Candidate 1 (RC1) der neuen Web Application Security Risks Top Ten, besser bekannt als OWASP Top Ten. Die Unterscheidung ist wichtig, da es insgesamt mehr als 17 themenspezifische Top Ten gibt – auf einige werde ich am Ende des Artikels kurz eingehen. Die Top Ten für Webapplikationen sind wahrscheinlich das bekannteste Projekt von OWASP und geben einen Überblick über die wichtigsten Risiken, die Webanwendungen betreffen.

Das Ziel der OWASP Top Ten ist es, für Anwendungssicherheit zu sensibilisieren, indem es einige der kritischsten Risiken aufzeigt. Die erste Version der OWASP Top Ten entstand schon im Jahr 2003. Ab der Version 2010 ist der Fokus von konkreten technischen Schwachstellen auf allgemeine Risiken bzw. Bedrohungen umgeschwenkt. Mit der Version 2021 wurde dann eine neue Methode zur Berechnung des Risikos eingeführt, die auch bei der Version 2025 mit Anpassung wieder genutzt wurde.

Auch diese Version der Top Ten basiert wieder auf Daten, die von OWASP erhoben werden. Einige große Organisationen, manche öffentlich und manche anonym, spenden hierzu Daten über ihre Security Vorfälle. Die Auswertung der bereitgestellten Daten ist im Wesentlichen ein Blick in die Vergangenheit, somit besteht auch das erhebliche Risiko, dass bestimmte Schwachstellen nicht zuverlässig in den Daten enthalten sind bzw. aktuelle Trends nicht ausreichend abgebildet werden. Um dem entgegenzuwirken, wurden im Rahmen einer Community-Umfrage Fachleute aus den Bereichen Anwendungssicherheit und -entwicklung befragt, welche Risiken ihrer Meinung nach in den Daten möglicherweise nicht ausreichend berücksichtigt werden. Bei der Auswertung der Daten wurden zwölf Kategorien bewertet und zwei davon aufgrund der Antworten aus der Community-Umfrage heraufgestuft oder hervorgehoben.

In Bild 1 wird schematisch gezeigt, wie ein Risiko zustande kommt. Hierbei sind die folgenden Punkte wichtig:

• Angreifer können viele verschiedene Angriffswege verwenden.
• Jeder Angriffsweg stellt ein Risiko dar! Der mögliche Schaden variiert.
• Das Gesamtrisiko kann nur durch die Betrachtung aller relevanten Faktoren abgeschätzt werden:
  • Die Wahrscheinlichkeiten für Bedrohungsquellen, Angriffsvektoren und Sicherheitsschwachstellen
  • Auswirkungen (technische und auf Unternehmen)
     

Die OWASP Top Ten ist der Versuch die zehn größten Risiken für Webanwendungen zu ermitteln. Hierbei ist es wichtig zu verstehen, dass es mehr als nur diese zehn Risiken gibt. Zum Beispiel haben es Memory Corruption Angriffe nicht mehr in die Top Ten geschafft, erzielen aber weiterhin die höchsten Bug Bounties aufgrund ihres hohen Impacts. Man sollte die Top Ten also nicht als Checkliste sehen, um “sicher zu sein”, sondern als eine gute Baseline, um sich weiteren Risiken zu widmen, z.B. Risiken auf der fachlichen Ebene. In der Tabelle auf der Top Ten Seite wird gezeigt, wie gut sich die OWASP Top Ten bei verschieden Szenarien eignet.

Als nächstes betrachten wir die Änderungen gegenüber der letzten Version 2021 (siehe Bild 2) und anschließend die Liste der Risiken mit meiner persönlichen Meinung/Einschätzung zu diesen.

A01:2025 - Broken Access Control (Fehler in der Zugriffskontrolle)

• Mit einer Zugriffskontrolle werden Richtlinien durchgesetzt, sodass ein User nicht außerhalb seiner Berechtigungen agieren kann. Hierbei führen Fehler in der Regel zur unbefugten Offenlegung, Änderung oder Zerstörung von Daten oder zur Ausführung einer Geschäftsfunktion außerhalb der Berechtigung des Users.
• Das Risiko Server-Side Request Forgery (SSRF) der Version 2021 wurde in das Risiko Broken Access Control integriert.
• Aus meiner Erfahrung heraus kann ich bestätigen, dass der erste Platz absolut berechtigt ist. 
  Zugriffskontrolle ist das Kernthema für Software-/System-Sicherheit ganz allgemein und zieht sich auch durch den gesamten Entwicklungsprozess. Am Anfang müssen im Requirements Engineering erst die benötigten Rechte, Rollen usw. erarbeitet werden. Am Ende muss dieses Berechtigungskonzept auch korrekt in allen Softwarekomponenten implementiert werden. Bei den heutigen durchaus komplexen und vernetzten Systemen ist das eindeutig die größte Herausforderung.

A02:2025 - Security Misconfiguration (Fehlerhafte Sicherheitskonfiguration)

• Eine Sicherheitsfehlkonfiguration liegt vor, wenn ein System, eine Anwendung oder ein Cloud-Dienst aus Sicherheitsperspektive falsch eingerichtet ist und dadurch Schwachstellen entstehen.
• In meiner Praxis erlebe ich immer wieder, dass z.B. Klassennamen oder Stacktraces in den Fehlermeldungen nach extern mitgegeben werden. Zudem werden die default Konfigurationen nicht daraufhin geprüft, ob sie sicher sind, insbesondere wenn nach einem Update neue dazugekommen sind. Auch kommt es vor, dass Cloud Services versehentlich öffentlich exponiert oder Prüfmechanismen deaktiviert werden.

A03:2025 - Software Supply Chain Failures (Software Lieferketten Versäumnisse)

• Versäumnisse in der Software-Lieferkette sind Störungen oder andere Beeinträchtigungen beim Erstellen, Verteilen oder Aktualisieren von Software. Sie werden häufig durch Schwachstellen oder böswillige Änderungen in Codes, Tools oder anderen Abhängigkeiten von Drittanbietern verursacht, auf die das System angewiesen ist.
• Die Erweiterung des alten Controls 6 (Vulnerable and Outdated Components) um die Software Supply Chain finde ich sehr sinnvoll, insbesondere wenn man sich die aktuelle Bedrohungslage (z.B. Shai Hulud, React2Shell ) ansieht. Es geht nicht mehr nur um Schwachstellen, sondern auch Backdoors bzw. ganz allgemein Angriffe auf meine Zulieferer (ja, darunter fällt auch Open Source Code). Auch wichtig ist eine regelmäßige Kontrolle der Anwendungen auf bekannte Schwachstellen und die zeitnahe Behebung von diesen. Hierbei ist die Nutzung von SBOMs (Software Bill of Materials) sinnvoll, da es die Arbeit erleichtert, man eine SBOM auch von Zulieferern fordern kann und SBOMs auch bei anderen Prozessen verwendet werden (z. B. Lizenz-Prüfung, Software Provenance). In meinen Augen der größte Vorteil bei der Schwachstellen-Erkennung ist aber, dass die meisten Scanner mit SBOMs umgehen können und so ein Wechsel des Scanners weniger aufwendig ist.

A04:2025 - Cryptographic Failures (Kryptographische Fehler)

• Generell sollten alle übertragenen Daten auf der Transportschicht (OSI-Schicht 4) verschlüsselt werden. Über die Sicherung der Transportschicht hinaus ist es wichtig zu bestimmen, welche Daten im Ruhezustand und welche während der Übertragung (auf der Anwendungsschicht, OSI-Schicht 7) zusätzlich verschlüsselt werden müssen. Beispielsweise erfordern Passwörter, Kreditkartennummern, Gesundheitsdaten, personenbezogene Daten und Geschäftsgeheimnisse einen zusätzlichen Schutz. Insbesondere wenn diese Daten unter Datenschutzgesetze fallen, z. B. die Datenschutz-Grundverordnung (DSGVO) der EU oder Vorschriften wie den PCI-Datensicherheitsstandard (PCI DSS). Wichtig ist, es geht nicht nur um reine Verschlüsselung, sondern um alle kryptographischen Methoden wie z. B. Hash-Funktionen oder digitale Signaturen.
• Ein häufiger Fehler, den ich aus dem Alltag kenne, besteht darin, dass Verschlüsselungs-Algorithmen genutzt werden, die nicht mehr sicher sind, eine zu kurze Schlüssellänge zum Einsatz kommt oder eine default Implementierung genutzt wird, die noch auf veraltete Verfahren setzt. Ich empfehle hier einen regelmäßigen Prozess zu etablieren, um zu prüfen, ob alle verwendeten Algorithmen und Schlüssellängen noch den aktuellen Best Practices entsprechen. Dazu kann ich die technische Richtline des BSI’s TR-02102 empfehlen. In dieser werden z. B. auch quantensichere Verfahren (“Post-Quantum Crypto”) betrachtet, die in den nächsten Jahren noch verstärkt ein Thema werden.

A05:2025 - Injection (Injektion inkl. XSS)

• Eine Injektion-Sicherheitslücke ist eine Systemschwäche, die es einem Angreifer ermöglicht, bösartige Befehle in einem Interpreter auszuführen, als wären diese ein Teil des Systems. Dies führt oft zu schwerwiegenden Folgen (z. B. Datenexfiltration der Datenbank, Passwort Leaks, Leaks von personenbezogenen Daten usw.). Einige der häufigsten Injektionsarten sind SQL-, NoSQL-, OS-Befehl-, ORM-, LDAP-, Prompt- und EL- oder OGNL-Injektionen.
• Diese Schwachstelle ist seit Jahrzehnten bekannt und gehört zu den gefährlichsten technischen Schwachstellen. Ich persönlich finde es erschreckend, dass sie dennoch weiterhin in der Top Ten vorkommt, denn es gibt mittlerweile genügend Maßnahmen bzw. Libraries, um sie grundsätzlich zu vermeiden. Seit der Version 2021 ist diese Art der Schwachstelle nicht mehr auf Platz eins und mit dem jetzigen RC auch von Platz drei auf fünf gefallen. Daran ist zu erkennen, dass dieses Problem so langsam ins Bewusstsein aller Beteiligten rückt.

A06:2025 - Insecure Design (Unsicheres Design)

• Unsicheres Design oder Konzeption ist eine weit gefasste Kategorie. Was beachtet werden muss, ist, dass es einen Unterschied zwischen unsicherem Design und unsicherer Implementierung gibt. Diese Unterscheidung ist wichtig, da sie unterschiedliche Ursachen haben, zu unterschiedlichen Zeitpunkten im Entwicklungsprozess auftreten und unterschiedliche Abhilfemaßnahmen erfordern. Ein sicheres Design kann dennoch Implementierungsfehler aufweisen, die zu Schwachstellen führen, die ausgenutzt werden können. Ein unsicheres Design kann nicht durch eine perfekte Implementierung behoben werden, da die erforderlichen Sicherheitskontrollen zum Schutz vor bestimmten Angriffen nie erstellt wurden.
• Wenn schon beim Design auf Sicherheit geachtet wird, dann erhöht dies die Sicherheit deutlich und senkt zugleich die Kosten, da die Behebung einer Schwachstelle umso teurer wird, je später sie gefunden wird.

A07:2025 - Authentication Failures (Fehler bei der Authentifizierung)

• Wenn ein Angreifer ein System dazu bringen kann, einen ungültigen oder falschen User als legitim zu erkennen, liegt ein Fehler bei der Authentifizierung vor.
• Da es mittlerweile Millionen von bekannten Benutzerdaten gibt, nutzen Angreifer diese oft, um sich auch bei anderen Anwendungen Zugang zu verschaffen, denn User verwenden oft die gleichen Logindaten bei verschiedenen Anwendungen. Auch das Problem von unsicheren Passwörtern oder schlecht abgesicherten Logins ist eine Schwachstelle, die ich regelmäßig sehe. Da bei diesem Risiko der Faktor Mensch eine große Rolle spielt, wird diese Schwachstelle wahrscheinlich nie vollständig verschwinden.

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

• Software- und Datenintegritätsfehler betreffen Code und Infrastruktur, die keinen Schutz vor ungültigen oder nicht vertrauenswürdigen Komponenten bieten und diese irrtümlich als gültig bzw. vertrauenswürdig behandeln. Ein Beispiel hierfür ist eine Anwendung, die auf Plugins, Bibliotheken oder Module aus nicht vertrauenswürdigen Quellen zurückgreift. Auch eine unsichere CI/CD-Pipeline ohne Verwendung und Bereitstellung von Software-Integritätsprüfungen kann das Risiko von unbefugtem Zugriff, unsicherem oder bösartigem Code oder einer Gefährdung des Systems mit sich bringen. Zudem verfügen heutzutage viele Anwendungen über eine automatische Update-Funktion, bei der Updates meist ohne ausreichende Integritätsprüfung heruntergeladen und auf die zuvor vertrauenswürdige Installation angewendet werden.
• Eine wichtige Kategorie, die meiner Erfahrung nach oft unterschätzt wird. Gerade in der Entwicklerinfrastruktur gibt es oft sehr viele Möglichkeiten Source Code oder Build Artefakte nachträglich zu verändern. Ein Beispiel: die Container-Images für die Produktionsumgebung werden aus einem Repository gezogen, auf das auch die Entwickler*innen Schreibzugriff haben. Damit könnte ein Developer (bzw. ein kompromittierter Developer-Laptop) das Container-Image einfach austauschen, ohne dass es vorher durch den regulären Release-Prozess gelaufen ist.

A09:2025 - Logging & Alerting Failures (Fehler bei der Protokollierung und Alarmierung)

• Ohne Protokollierung und Überwachung können Angriffe und Sicherheitsverletzungen nicht erkannt werden, und ohne Alarmierung ist es sehr schwierig, bei einem Sicherheitsvorfall schnell und effektiv zu reagieren.
• Insbesondere die Alarmierung und Reaktion auf diese, sollte auch in den Rand-Arbeitszeiten sichergestellt werden. Angreifer nutzen gerne verlängerte Wochenenden oder Feiertage, wenn die Besetzung in den Abteilungen reduziert ist. Wenn z.B. über Ostern niemand auf die Alarme reagiert, kann ein Angreifer von Donnerstagabend bis Dienstagmorgen frei agieren. Auch ist es wichtig, dass beim Logging alle wichtigen Informationen protokolliert werden, damit man eine Chance hat, den Angriff zu analysieren. Meiner Meinung nach sollte man nach einem Angriff ein Post-Mortem machen, um für zukünftige Angriffe besser gerüstet zu sein. Ich befürworte auch, dass nun das Thema Alarmierung stärker hervorgehoben wird. Auch wenn viele Organisationen aus Compliance-Gründen Logging implementiert haben, so wird dann oft vergessen, die Logs auch auszuwerten und am Ende hat man viele Daten produziert, aber wenig Mehrwert generiert. Automatische Logauswertung und Alarmierung können hier einen echten Mehrwert für Sicherheit und Betrieb bieten.

A10:2025 - Mishandling of Exceptional Conditions (Fehler beim Umgang mit außergewöhnlichen Bedingungen)

• Außergewöhnliche Bedingungen können durch fehlende, mangelhafte oder unvollständige Eingabevalidierung, durch verspätete Fehlerbehandlung oder durch unerwartete Umgebungszustände (wie z. B. Speicher-, Berechtigungs- oder Netzwerkprobleme, inkonsistente Ausnahmebehandlung oder überhaupt nicht behandelte Ausnahmen) verursacht werden. Hierdurch kann das System in einen unbekannten und unvorhersehbaren Zustand geraten. Schwer zu findende Fehler und Ausnahmen können die Sicherheit der gesamten Anwendung für lange Zeit gefährden. Eine fehlerhafte Behandlung beim Umgang mit außergewöhnlichen Bedingungen tritt auf, wenn Anwendungen ungewöhnliche und unvorhersehbare Situationen nicht verhindern, erkennen und darauf reagieren können. Dies kann zu Abstürzen, unerwartetem Verhalten und manchmal zu Sicherheitslücken führen.
• Bei Pentests zeigt sich immer wieder, dass unsauber implementiertes Exceptionhandling dazu führt, dass Stacktraces oder Klassennamen mit nach außen gegeben werden. Durch diese Informationen erfährt ein Angreifer Interna der Anwendung, die er für weitere Angriffe nutzen kann.

Aktuell haben es diese beiden Risiken nicht in die Top Ten geschafft, sie könnten aber in der finalen Version enthalten sein. Aus diesem Grund werden wir auch sie kurz betrachten.

X01:2025 Lack of Application Resilience (Fehlende Anwendungsrobustheit)

• Bei diesem Risiko wird die systemische Schwäche in der Art und Weise, wie Anwendungen auf Stress, Ausfälle und Randfälle reagieren, betrachtet. Wenn eine Anwendung unerwartete Bedingungen, Ressourcenengpässe und andere widrige Ereignisse nicht ordnungsgemäß verarbeitet, ihnen nicht standhält oder sich nicht davon erholt, kann dies leicht zu Verfügbarkeitsproblemen (am häufigsten), aber auch zu Datenbeschädigungen, Offenlegung sensibler Daten, Kettenausfällen und/oder Umgehungen von Sicherheitskontrollen führen.
• Eine Anwendung sollte immer so implementiert werden, dass sie sich in einem sicheren Zustand befindet. Ein einfaches Beispiel zum Verdeutlichen ist meiner Meinung nach der Geldautomat, der in jedem Fall (z. B. Stromausfall) verhindern muss, dass das Geld in unbefugte Hände gerät. Dies ist für mich inhaltlich ähnlich zu A10:2025 - Mishandling of Exceptional Conditions.

X02:2025 Memory Management Failures (Fehler im Speichermanagement)

• Wenn eine Anwendung gezwungen ist, den Speicher selbst zu verwalten, können sehr leicht Fehler auftreten. Speichersichere Sprachen werden zwar immer häufiger verwendet, aber weltweit gibt es immer noch viele Legacy-Systeme in Produktion, neue Low-Level-Systeme, die die Verwendung nicht speichersicherer Sprachen erfordern, und Webanwendungen, die mit Mainframes, IoT-Geräten, Firmware und anderen Systemen interagieren, die möglicherweise ihren eigenen Speicher verwalten.
• Die bekanntesten Schwachstellen, die zu diesem Risiko gehören sind wohl Buffer Overflows. Der Impact dieser Art von Schwachstellen ist oft sehr hoch (oft Remote Code Execution). Für Hersteller von Betriebssystemen und kritischen Systemkomponenten ist dies weiterhin ein Problem, da hier noch viel Legacy (z. B. C/C++) Code eingesetzt wird. Für den Großteil der Entwickler*innen ist dies kein großes Thema mehr, da hier die meisten Teams mit speichersicheren Sprachen arbeiten. Ich denke, es ist daher gerechtfertigt, dass diese Art von Schwachstellen nicht mehr in den Webapplikation Top Ten vertreten ist.

Ich gehe davon aus, dass die finale Liste der Top Ten sich nach diesem Release Candidate im Großen und Ganzen nicht mehr stark ändern wird, da sie meiner Meinung nach sehr passend ist. Ich denke auch, dass es X01 und X02 wahrscheinlich nicht in die Top Ten schaffen, aber an den beiden Risiken (und es gibt noch weitere) kann man erkennen, dass hier nur die zehn wichtigsten und nicht alle Schwachstellen aufgezeigt werden. Wenn man nur die Top Ten angeht, hat man sich zwar um die größten Risiken gekümmert, aber keine Garantie, dass man nicht Opfer eines Angriffs wird. Trotzdem gilt: die Top Ten ist ein sehr guter Anfang.

Diese sind meistens keine Flagship Projekte der OWASP, aber auch sehr empfehlenswert. Aus diesem Grunde möchte ich einige davon hier kurz nennen, da sie in meinen Augen für bestimmte Themen besser passen. Oft ist auch eine Verwendung von mehreren Top Ten in Kombination sinnvoll. Einige Beispiele:

API Security

• aktuelle Version 2023
• Diese Top Ten ist eine gute Ergänzung, wenn man eine API anbietet (explizit oder implizit). Viele Punkte aus der Web Application Security Risks Top Ten sind auch in dieser Top Ten enthalten, wie z. B. Sicherheitsfehlkonfiguration.

Mobile Risks

• aktuelle Version 2024
• Bei dieser Top Ten liegt der Schwerpunkt auf den Risiken der mobile App selbst und ich halte sie für eine gute Ergänzung zu Mobile Application Security (MAS), dem Flagship Projekt der OWASP für mobile Anwendungen.

Proactive Controls

• Aktuelle Version 2024, aber die Version 2018 ist auch schon gut.
• Hier geht es einmal nicht um Risiken und Schwachstellen, sondern um Gegenmaßnahmen, die in der Applikation bzw. vor allem im Entwicklungsprozess umzusetzen sind. Sie sind also quasi das Gegenstück zu den bekannten Web App Top Ten Risiken. Die Proactive Controls Top Ten bietet eine gute Grundlage für einen sicheren Entwicklungsprozess. Ich würde eine Kombination der Version 2018 und 2024 nutzen, da z. B. Logging & Monitoring in der 2024 Version nicht mehr explizit genannt werden, diese aber in meinen Augen sehr wichtig sind.

Large Language Model Applications

• aktuelle Version 2025
• Ist eine neue Top Ten Liste, die 2025 das erste Mal als Teil des OWASP GenAI Security Projects veröffentlicht wurde. Sie geht auf die Risiken ein, die es bei der Verwendung von Large Language Models (LLM) bzw. Generative AI generell zu beachten gilt.

Zusammenfassend kann man sagen, dass die Top Ten Listen von OWASP ein wichtiges Instrument sind, um Awareness für Sicherheitsrisiken zu schaffen. Gerade durch den datenbasierten Prozess zur Erstellung der Web App Top Ten, kann man auch gut eine Priorisierung ableiten, wenn es darum geht, Security Themen umzusetzen. Allerdings gilt auch hier: Security ist immer vom Kontext abhängig. Was für die eine Organisation eine kritische Schwachstelle ist, kann für die andere nicht einmal ein Minor Version Upgrade wert sein. Es ist also essentiell, dass Security Prozesse immer von Expert*innen auf die jeweilige Organisation zugeschnitten werden. Hier helfen unsere Security Expert*innen gerne weiter!