Awareness für Web-Security: Die OWASP Top Ten 2025

Das Open Worldwide Application Security Project (OWASP) hat auf seiner Konferenz „Global AppSec USA“ den ersten Release Candidate der OWASP Top Ten 2025 vorgestellt: die Liste der größten Sicherheitsrisiken für Webanwendungen. Die letzte Liste erschien vor vier Jahren, in der schnelllebigen Welt der Webentwicklung eine lange Zeit. Grund genug, einen Blick auf die Neuerungen der achten Ausgabe zu werfen.

Top 1 bis 3

Die ersten drei Listenpunkte der OWASP Top Ten 2025 waren auch bereits in den vorherigen Ausgaben diejenigen Risiken, die mit Abstand am häufigsten auftreten. Insbesondere bei der alten und neuen Nummer Eins, „Broken Access Control“, liegt das an der großen Menge an Common Weakness Enumerations (CWEs), dem Nummerierungssystem für Sicherheitslücken und -risiken, das die Grundlage der OWASP Top Ten bildet. Dabei sind sagenhafte 40 Stück dieser Kategorie zugewiesen – ein neuer Rekordwert. Das ist auch einer meiner persönlichen Kritikpunkte an den Top Ten: Die Kategorie ist sehr breit und enthält neben abgehangenen Klassikern wie dem „Path Traversal“ auch Allgemeinplätze wie „Improper Access Control“ und „Improper Authorization“ sowie Cross-Site Request Forgery (CSRF) und Server-Side Request Forgery (SSRF). In der Praxis äußert sich Broken Access Control unter anderem in erratenen IDs in der URL, nicht gesicherten Endpunkten („Keiner errät, dass es die gibt!“) und anderen Verletzungen der Grundregel „Zugriffskontrolle, überall“.

Punkt 2 ist „Security Misconfiguration“, also eine mangelnde Konfiguration. Das ist mitnichten ein reines Administrations- oder Betriebsthema, denn diese Kategorie umfasst nicht nur die Härtung des Betriebssystems und der Serversoftware, sondern auch applikationsspezifische Einstellungen, etwa was mit Fehlermeldungen geschieht (Klassiker: direkt an den Client aka Angreifenden schicken). Ebenso gehört die Verwendung von sicherheitsrelevanten HTTP-Headern dazu, beispielsweise Content Security Policy und Referrer Policy. Die Existenz solcher Header lässt sich trivial überprüfen, weswegen ihr Fehlen in jedem Audit-Report bemängelt wird, unabhängig von der Qualität des Pentests. Ein Setzen dieser Header ist somit eine Win-Win-Situation: Die Anwendung ist sicherer, der Report kürzer. Diese Kategorie ist im Vergleich zur letzten Ausgabe 2021 um drei Plätze nach oben gerutscht, was sich mit zunehmend konfigurierbareren Webanwendungen erklären lässt.

Platz 3 heißt „Software Supply Chain Failures“, in der Vorgängerausgabe noch „Vulnerable and Outdated Components“ genannt und dort auf Platz 8. Der steile Anstieg erklärt sich durch die immer stärkere Abhängigkeit von Software-Paketen. Allein im Jahr 2025 gab es zahlreiche Vorfälle, bei denen etwa Bibliotheken und Dependencies mit Schadsoftware versehen wurden: Erweiterungen für Visual Studio Code, npm-Pakete (unter anderem durch Shai-Hulud und Shai-Hulud 2) und viele mehr. Eine einfache Lösung gibt es nicht: Eine Aktualisierung aller Software-Abhängigkeiten direkt nach Erscheinen konnte in den genannten Fällen zur Katastrophe führen, da sich in den neuen Versionen die Schadsoftware befand. Auf Updates zu verzichten oder sie lange aufzuschieben, ist aber ebenfalls keine Lösung – ab Bekanntwerden einer Sicherheitslücke tickt die Uhr. Eine häufig adäquate Strategie besteht darin, neue Versionen rasch einzuspielen und zusätzlich für eine hohe automatische Testabdeckung zu sorgen, um beim Updaten eine möglichst große Sicherheit zu haben, dass weiterhin alles so wie gewünscht funktioniert.

Im Gegensatz zur 2021er-Ausgabe ist diese Kategorie jetzt breiter – nicht nur die Abhängigkeiten, sondern die gesamte Infrastruktur zum Erstellen und Verteilen einer Anwendung, sprich die komplette Supply Chain, gehört dazu. Die hohe Position in der Liste resultiert nicht aus den zugrunde liegenden Daten, sondern aus einer separaten Umfrage darüber, welche Sicherheitsaspekte in Pentests unterrepräsentiert sind (siehe Abschnitt „Entstehungsprozess der OWASP Top Ten“). Einige Supply-Chain-Risiken sind im Rahmen eines Audits schwer zu testen, doch ein Blick auf aktuelle Angriffe zeigt, dass das Problem real ist, sich aber in den Daten ungenügend widerspiegelt.

Top 4 bis 6

Auf Platz 4 der 2025er OWASP Top Ten befindet sich „Cryptographic Failures“, um zwei Plätze im Vergleich zu 2021 gefallen. Das lässt sich unter anderem dadurch erklären, dass sich die durchgängige Verwendung von HTTPS weitestgehend durchgesetzt hat, inklusive flankierender Maßnahmen wie der Beschränkung von Cookies auf einen sicheren Transportweg (secure-Flag) und dem Erzwingen von HTTPS – durch HTTP Strict Transport Security (HSTS), einem Mechanismus mittels HTTP-Header und damit ebenfalls ein Kandidat für Kategorie 2, „Security Misconfiguration“. Browser können sogar mit vorangemeldeten Domains automatisch ausschließlich mit HTTPS kommunizieren (siehe Abbildung 1). Auch das unsichere Speichern von Passwörtern, etwa mit MD5-Hash oder gar nur im Klartext, tritt in Audits viel seltener auf.

Listeneintrag Nummer 5 heißt „Injection“. Zum ersten Mal in der Geschichte der OWASP Top Ten findet sich dieser Punkt nicht in den Top 3. Bis einschließlich 2017 hieß die Kategorie ganz spezifisch „SQL Injection“, ist also nach einem Angriff benannt, der älter ist als das Web selbst. Und in der Tat ist das Einschleusen von bösartigem SQL bei Weitem nicht mehr so stark verbreitet wie noch in den 1990er und auch 2000er Jahren. Trotzdem hat sich „Injection“ bisher wacker in den Top Ten gehalten. 2021 war dies nur durch einen Kniff der OWASP möglich: Sie hat damals nämlich nicht nur die Kategorie von „SQL Injection“ in „Injection“ umbenannt, sondern auch deutlich erweitert: durch den Dauerbrenner XSS (Cross-Site Scripting). Das ist thematisch durchaus korrekt – selbst wenn der Kategoriename es nicht vermuten lässt –, denn XSS geht in der Regel mit dem Einschleusen von bösartigem HTML-Markup oder JavaScript-Code einher. Es liegt somit eine Injection vor.

Dass SQL Injection an Verbreitung verliert, hat nicht nur damit zu tun, dass klassische Gegenmaßnahmen wie Prepared Statements oder parametrisierte Abfragen mittlerweile zum Allgemeinwissen gehören sollten (auch wenn das in der Realität nicht immer der Fall ist). In vielen Anwendungen wird SQL nicht mehr explizit, sondern nur noch implizit eingesetzt: Die Anwendung kommuniziert mit der Datenbank über einen objektrelationalen Mapper wie Hibernate, Entity Framework Core oder Doctrine, was SQL Injection zwar nicht unmöglich macht, aber stark erschwert.

XSS wiederum ist ein anhaltendes Problem, doch es gibt inzwischen bessere Gegenmaßnahmen als noch 1998, als der Begriff geschaffen wurde. Viele Frameworks enthalten Schutzkonzepte, beispielsweise ein Ausgabe-Escaping in Single-Page-Application-Technologien wie Angular, React oder Vue.js. Mit Content Security Policy gibt es einen Defense-in-Depth-Mechanismus, der zwar keine XSS-Lücken schließt, aber deren Ausnutzung sehr schwer bis unmöglich machen kann. Die Trusted Types API bietet insbesondere für JavaScript-basierte Webanwendungen einen gewissen Schutz vor XSS. Sie ist jedoch im Firefox-Browser noch nicht ohne Extra-Konfiguration verfügbar.

Etwas enttäuschend wiederum ist Punkt 6 der OWASP Top Ten, vor vier Jahren noch auf Platz 4: „Insecure Design“. In der Tat ist ein unsicheres Softwaredesign ein großes Risiko, und es bietet sich an, gemäß „Shift Left“-Paradigma möglichst früh im Softwareentwicklungsprozess die Sicherheit mit einzubeziehen, aber konkret greifbar ist dieses Listenelement nicht. Eine Gegenmaßnahme zu „unsicherem Design“ wäre „sicheres Design“.

Top 7 bis 10

Platz 7 der OWASP Top Ten 2025 heißt „Authentication Failures“, etwas griffiger als die Kategorie in der Ausgabe 2021, die „Authentication and Authentication Failures“ lautete. Hier versammeln sich fast so viele CWEs wie auf Platz 1, nämlich insgesamt 36 Stück. Authentifizierung hat im Web viele Facetten, seien es Sessions – samt zugehörigen Angriffen, auch wenn diese sich in modernen Browsern häufig sehr gut verhindern lassen – oder modernere Mechanismen wie etwa OpenID Connect. Für letztere gibt es zwar eine gute Unterstützung in den verschiedenen Frameworks, inklusive zertifizierter Implementierungen. Allerdings birgt die Komplexität auch Risiken, die sich in der Platzierung der Kategorie in den OWASP Top Ten widerspiegeln.

Auf Platz 8 befindet sich „Software or Data Integrity Failures“ – 2021 war statt „or“ noch ein „and“ im Titel. In dieser Kategorie geht es im Wesentlichen um die Prüfung der Integrität an jeder Stelle, beispielsweise vor und nach jedem Schritt in der CI/CD-Pipeline. Auch beim Deserialisieren gilt es, immer auf einen bestimmten Ziel-Datentypen zu prüfen; Frühere Ausgaben der OWASP Top Ten wiesen gar einen eigenen Punkt auf, „Insecure Deserialization“, der durch teilweise bessere Standardeinstellungen in Frameworks an Relevanz verloren hat.

Ein kleines, aber feines Sicherheitsfeature eignet sich für viele Webanwendungen, die JavaScript einsetzen, insbesondere, wenn dieser Code aus einem Content Delivery Network (CDN) stammt (was hinsichtlich einer Content Security Policy, siehe Punkt 5, nicht optimal ist). Moderne Browser unterstützen Sub-Resource Integrity (SRI), was sich im Wesentlichen auf das integrity-Attribut für