Die OWASP Top 10 gelten als globaler Standard für Web Application Security. Sie zeigen, wo die größten Risiken liegen und wo Unternehmen besonders genau hinschauen sollten. Die aktuellen Top 10 von 2025 wurden letzte Woche auf der OWASP Global AppSec USA 2025 vorgestellt und macht deutlich: Klassische Schwachstellen wie SQL-Injection verlieren an Bedeutung. Stattdessen rücken komplexere Angriffe in den Fokus, etwa in der Business-Logik, der Software-Lieferkette oder der Fehlerbehandlung. Als eines der wenigen europäischen Unternehmen haben wir als usd AG die Erkenntnisse aus unseren Web Application Pentests eingebracht, sodass die OWASP Top 10 nun nicht nur globale Trends abbilden, sondern auch reale Schwachstellen aus dem deutschen Markt widerspiegeln. Ein Beitrag ganz im Sinne unserer Mission: more security.
Die OWASP Top 10 sind für uns ein wichtiger Indikator. Sie zeigen, wo die globalen Trends bei Schwachstellen in Webanwendungen liegen. Aber in unserem Kernmarkt Deutschland erkennen wir viele dieser Entwicklungen oft früher. Da wir jährlich eine signifikante Anzahl an Webanwendungen pentesten, haben wir ein klares Bild darüber, wohin sich Bedrohungen bewegen. Deshalb haben wir dieses Jahr aktiv mitgewirkt und unsere Erfahrungen eingebracht, indem wir unsere Findings anonymisiert als Daten gespendet haben. Unser Ziel: Die Liste nicht nur widerspiegeln, sondern für mehr Praxisbezug mitgestalten.
Matthias Göhring, Head of usd HeroLab
In diesem Beitrag zeigen wir die wichtigsten Erkenntnisse aus der neuen OWASP Top 10, wie sich die Risikolandschaft verändert hat und welche Maßnahmen Unternehmen jetzt ergreifen sollten.
Platz 1: Broken Access Control bleibt unangefochten vorn
Broken Access Control bezeichnet Schwachstellen, bei denen Autorisierungsprüfungen fehlen oder fehlerhaft sind, sodass Angreifer Funktionen ausführen oder Daten einsehen können, für die sie nicht berechtigt sind. Diese stellen weiterhin das größte Risiko dar. Warum? Weil diese Kategorie stark mit der spezifischen Business-Logik einer Anwendung verknüpft ist und durch Frameworks kaum automatisch verhindert wird.
Typische Ursachen:
- Ungeschützte API-Endpunkte
- Übergabe sensibler Daten ohne Berechtigungsprüfung
- Falsche Annahmen über vertrauenswürdige Clients
Unsere Empfehlung: Ein effektiver Schutz erfordert ein klar definiertes Berechtigungsmodell und die konsequente Durchsetzung von Autorisierungschecks an allen relevanten Schnittstellen. Automatisierte Tests decken hier nur Teilbereiche ab, weshalb manuelle Überprüfungen und gezielte Pentests unerlässlich sind.
Platz 2: Security Misconfiguration
Von Platz 5 auf Platz 2: Nahezu alle Anwendungen bieten Konfigurationsoptionen an, um diese auf die individuellen Anforderungen und Umgebungen anzupassen, beispielsweise eigene Zertifikate zu hinterlegen. Durch Fehlkonfigurationen oder bestimmte Kombinationen von Einstellungen können hier Sicherheitslücken entstehen, z.B. durch unveränderte Standardkonten oder falsch gesetzte Berechtigungen in Cloud-Umgebungen.
Unsere Empfehlung: Setzen Sie auf einen wiederholbaren Hardening-Prozess. Prüfen Sie, ob die Hersteller der Software eine Härtungsrichtlinie bereitstellen. Anhand dieser sollte ebenfalls geprüft werden. Zudem entfernen Sie unnötige Komponenten und prüfen Sie Konfigurationen regelmäßig, mindestens jährlich manuell.
Neu auf Platz 3: Software Supply Chain Failures
Neu im Ranking und direkt auf Platz drei: Software Supply Chain Failures. Diese Kategorie ersetzt den bisherigen Punkt „Using Vulnerable and Outdated Components“ und erweitert den Blick auf Angriffe auf sämtliche Teile der Software-Lieferkette. Dazu gehören kompromittierte Bibliotheken in öffentlichen Paketquellen, manipulierte Build-Prozesse oder Schadcode in externen Abhängigkeiten. Die Zunahme dieser Risiken ist direkt auf reale Vorfälle zurückzuführen, bei denen Supply Chains gezielt als Einfallstor für Angriffe genutzt wurden.
Unsere Empfehlung: Setzen Sie technische Maßnahmen sinnvoll ein, wie eine vollständige Software Bill of Materials (SBOM), automatisierte Scans von Abhängigkeiten, Code-Signing eigener Artefakte und eine strikte Isolation der Build-Umgebung von produktiven Systemen. Weiterhin sollten Sie kontinuierlich und automatisiert prüfen, ob von verwendeten Bibliotheken neuere Versionen mit Sicherheitspatches vorhanden sind und diese zeitnah aktualisieren.
Injection-Schwachstellen sinken – SQLi, SSTI und XSS bleiben relevant
Die Kategorie Injection ist im neuen Ranking um zwei Plätze auf Platz 5 gefallen. Dieser Rückgang ist vor allem auf die wachsende Entwickler-Awareness und den Einsatz moderner Frameworks zurückzuführen, die standardmäßig mit Parametrisierung, automatischem Escaping und Input-Validierung arbeiten. Dennoch bleiben drei Unterformen selbst in aktuellen Projekten präsent:
- SQL-Injection (SQLi): Tritt auf, wenn ungeprüfter Benutzerinput direkt in SQL-Statements eingefügt wird. Sie kann zum Abzug kompletter Datenbanken, zur unautorisierten Manipulation von Daten oder zur Eskalation weiterer Angriffe genutzt werden. Moderne ORMs verhindern SQLi in vielen Fällen automatisch; in Legacy-Systemen oder bei dynamisch zusammengesetzten Abfragen ist die Gefahr jedoch weiterhin hoch.
- Server-Side Template Injection (SSTI): Ist ein moderneres Risiko und entsteht, wenn Template-Engines wie Jinja2, Twig oder Freemarker unvalidierte Eingaben verarbeiten. Dadurch können Angreifer serverseitig Code ausführen oder interne Daten abfragen. Besonders gefährdet sind Anwendungen, in denen Entwickler erweiterte Template-Funktionen aktivieren oder auf unsichere dynamische Syntax setzen.
- Cross-Site Scripting (XSS): Zielt dagegen auf den Client ab und ermöglicht das Ausführen von JavaScript im Browser eines Opfers. Risiken bestehen insbesondere bei DOM-basiertem XSS in komplexen Single-Page-Anwendungen und bei unzureichendem Kontext-Encoding. Folgen reichen von Session Hijacking über Datenabgriff bis zu UI-Manipulationen.
Unsere Erfahrungen aus Pentests zeigen: Generell treten Injection-Schwachstellen sowohl SQL-Injection als auch XSS und SSTI heute deutlich seltener auf. Moderne Anwendungen sind hier meist gut abgesichert, denn aktuelle Frameworks und Technologien verhindern viele dieser Angriffe bereits standardmäßig. In älteren Systemen sieht das anders aus: Dort begegnen uns diese Schwachstellen nach wie vor deutlich häufiger.
Neu aufgenommen: Mishandling Exceptional Conditions
Eine komplett neue Kategorie ist Mishandling Exceptional Conditions. OWASP fasst hier 24 CWE-Klassifizierungen zusammen, deren gemeinsamer Nenner eine unsichere oder fehlerhafte Fehlerbehandlung ist. Technische Risiken entstehen zum Beispiel, wenn detaillierte Fehlermeldungen sensible Informationen verraten, wenn Ausnahmefälle unbemerkt Sicherheitsprüfungen umgehen oder wenn nach einem fehlerhaften Vorgang sicherheitsrelevante Zustände nicht korrekt zurückgesetzt werden.
In der Praxis treten solche Probleme oft zusammen mit Schwachstellen in der Zugriffskontrolle auf, etwa wenn ein Ausnahmefall einen alternativen Programmpfad ohne Autorisierungsprüfung auslöst. Die Folge: Zugriff auf Funktionen, die eigentlich geschützt sein sollten.
Unsere Empfehlung: Entwickeln Sie wirksame Gegenmaßnahmen, wie eine einheitliche und sichere Exception-Handling-Strategie, generische statt detailreicher Fehlermeldungen und gezieltes Testen von Fehler- und Sonderfällen.
Unser Fazit zu den OWASP Top 10: Der Fokus verschiebt sich
(Quelle: OWASP Top 10)
Die OWASP Top 10 im Jahr 2025 zeigen: Technische Fortschritte haben klassische Schwachstellen reduziert. Doch neue Risiken entstehen dort, wo Prozesse komplexer und weniger standardisiert sind. Die Implementierung von Zugriffskontrollen erfordert die Ausarbeitung eines konsistenten Berechtigungskonzepts und eine vollständige Implementierung. Da hier häufig Fehler passieren, bleibt Broken Access Control auf Platz 1. SQLi ist zwar rückläufig, während SSTI und XSS in modernen, dynamischen Anwendungen unverändert relevant bleiben. Supply Chain Failures machen den Einfluss externer Komponenten und Prozesse auf die Sicherheit deutlich, Mishandling Exceptional Conditions rückt die Bedeutung robuster Fehlerbehandlung ins Bewusstsein.
Für Entwickler*innen und Sicherheitsteams bedeutet das: Neben der klassischen Eingabevalidierung müssen Business-Logik, Lieferketten und Ausnahmebehandlung gleichwertig adressiert werden. Sicherheit darf nicht als eine Frage einzelner Funktionen oder Framework-Maßnahmen verstanden werden, sondern als durchgehender Qualitätsprozess - mit regelmäßigen Pentests, klaren Richtlinien und der Bereitschaft, auch unscheinbare Pfade auf Schwachstellen zu prüfen.
