OWASP Top 10:2025 — Zwei neue Kategorien und fundamentale Neupriorisierung von Anwendungssicherheitsrisiken

Die OWASP Top 10:2025 führt zwei neue Kategorien ein und implementiert erhebliche Umpositionierungen bestehender Risiken, was widerspiegelt, dass sich die Bedrohungslandschaft von isolierten Code-Fehlern hin zu systemischen Schwachstellen verschoben hat, die gesamte Entwicklungszyklen betreffen. Software Supply Chain Failures etabliert sich als dritthöchstes Risiko und adressiert die wachsende Sophistikation von Angriffen auf Abhängigkeiten und Build-Infrastruktur, während Mishandling of Exceptional Conditions auf Position zehn debütiert und anerkennt, dass Fehlerbehandlung eine fundamentale Sicherheitskontrolle darstellt. Gleichzeitig rückt Security Misconfiguration von Position fünf auf Position zwei vor, während Server-Side Request Forgery in Broken Access Control konsolidiert wurde.

Methodologischer Ansatz und Datengrundlage

Die Priorisierungsmethodologie für 2025 balanciert mehrere Risikodimensionen statt sich auf einzelne Metriken zu verlassen. OWASP berechnete Inzidenzraten, indem bestimmt wurde, welcher Prozentsatz getesteter Anwendungen mindestens eine Instanz jeder CWE-Kategorie enthielt. Die Analyse umfasste Daten von über 2,8 Millionen Anwendungen, was die umfassendste Schwachstellendatensammlung darstellt, die jemals zusammengestellt wurde. Der endgültige Risk-Scoring-Algorithmus integrierte fünf Dimensionen: maximale Inzidenzrate, maximale Abdeckung, durchschnittlicher Exploit-Score, durchschnittlicher Impact-Score und Gesamtvorkommnisse.

A03:2025 Software Supply Chain Failures: Kritisches Ökosystem-Risiko

Software Supply Chain Failures stellt eine Weiterentwicklung der 2021er Kategorie „Vulnerable and Outdated Components" dar. Die 2025er Expansion erkennt an, dass die Supply Chain jede Komponente und jedes Tool umfasst, das am Erstellen, Integrieren, Testen und Verteilen von Software beteiligt ist – von Entwickler-Workstations über Build-Server bis zu Artefakt-Repositories.

Der SolarWinds-Orion-Angriff von 2020 demonstrierte das verheerende Potenzial von Supply-Chain-Angriffen, als Angreifer Zugang zu Build-Infrastruktur erhielten und bösartigen Code in legitime Softwareaktualisierungen einfügten, die an ungefähr achtzehntausend Organisationen verteilt wurden. Der GlassWorm-Supply-Chain-Angriff 2025 zielte auf den Visual Studio Code-Marketplace mit einem sich selbst replizierenden Wurm, der automatisch auf Entwickler-Maschinen aktualisiert wurde.

Diese Vorfälle heben kritische Aspekte hervor: Supply-Chain-Kompromittierungen können hunderttausende oder Millionen von nachgelagerten Benutzern durch einen einzigen Angriff beeinflussen, Erkennung wird exponentiell schwieriger, weil der bösartige Code legitim erscheint, und Angreifer zielen zunehmend auf Entwickler-Maschinen selbst ab.

OWASP empfiehlt umfassende Supply-Chain-Härtung, einschließlich Software Bill of Materials-Tracking, kontinuierliche Überwachung von Schwachstellenoffenlegungen, Härtung von Code-Repositories mit Branch-Schutz und Multi-Faktor-Authentifizierung, kontinuierliche Patches auf Entwickler-Workstations und starke Aufgabentrennung in Build-Pipelines.

A10:2025 Mishandling of Exceptional Conditions: Fehlerbehandlung als Sicherheitskontrolle

Mishandling of Exceptional Conditions hebt Phänomene, die zuvor als „Codequalitätsprobleme" kategorisiert wurden, in formale Sicherheitsrisikokategorien. Diese Kategorie reflektiert aufkommendes Verständnis, dass unsachgemäße Fehlerbehandlung exploitierbare Sicherheitsschwächen schafft.

Die Kategorie umfasst vierundzwanzig CWEs, die sich auf unsachgemäße Fehlerbehandlung, logische Fehler und „Fail-Open"-Bedingungen konzentrieren. Mishandling kann sich durch drei Fehlermodi manifestieren: Erstens, wenn Anwendungen nicht verhindern, dass außergewöhnliche Umstände überhaupt auftreten. Zweitens, wenn Fehler nicht erkannt werden – eine Funktion könnte Fehler-Rückgabecodes ignorieren, ohne Exceptions auszulösen. Drittens, wenn die Reaktion auf erkannte Fehler schlecht oder nicht vorhanden ist – eine Anwendung könnte rohe Stack-Traces mit sensiblen Systeminformationen anzeigen.

Der „Fail-Open"-Fehlermodus verdient besondere Aufmerksamkeit: Wenn eine Sicherheitskontrolle auf einen Fehler trifft und implizit Zugriff erlaubt statt ihn zu verweigern. Das Prinzip der sicheren Ausfallsicherheit erfordert, dass Systeme standardmäßig „verweigern", wenn Sicherheitskontrollen ausfallen.

Schlechte Fehlerbehandlung kann Race Conditions ermöglichen, betrügerische Transaktionen führen und Denial-of-Service-Angriffe verstärken. Die praktische Empfehlung beinhaltet strukturierte Exception-Behandlung auf jeder Code-Ebene mit aussagekräftigen Reaktionen, die das zugrunde liegende Problem adressieren.

A02:2025 Security Misconfiguration: Erhöhung auf zweite Priorität

Security Misconfiguration steigt von A05:2021 zu A02:2025 auf. Diese Umpositionierung reflektiert deutlich erhöhte Prävalenz in den Testdaten mit einer durchschnittlichen Inzidenzrate von 3,00 Prozent.

Die Kategorie umfasst sechzehn CWEs, die Konfigurationsprobleme in Systemen, Anwendungen und Cloud-Services adressieren. Häufige Szenarien beinhalten Standard-Konten mit bekannten Passwörtern, unnötige Features, die aktiviert bleiben, Verzeichnisauflistung, die nicht deaktiviert ist, und übermäßig ausführliche Fehlermeldungen, die Stack-Traces enthüllen. Cloud-Storage-Services leiden häufig unter Fehlkonfiguration, wo Standard-Sharing-Berechtigungen Daten dem öffentlichen Internet exponieren.

Persistente Top-Kategorien: A01, A04 und A05

A01:2025 Broken Access Control behält seine Position als ernsthaftestes Anwendungssicherheitsrisiko bei mit einer durchschnittlichen Inzidenzrate von 3,73 Prozent und vierzig zugeordneten CWEs. Die Kategorie umfasst unsichere direkte Objektreferenzen, Privilege-Escalation, CORS-Fehlkonfigurationen, Token-Manipulation und Server-Side Request Forgery.

A04:2025 Cryptographic Failures sinkt von A02:2021 zu A04:2025 ab mit einer durchschnittlichen Inzidenzrate von 3,80 Prozent. Häufige Szenarien beinhalten veraltete Verschlüsselungsalgorithmen, Standard-Kryptographieschlüssel, kryptographische Schlüssel in Source-Code-Repositories und fehlende Erzwingung der Verschlüsselung für sensible Daten in Transit.

A05:2025 Injection behält seine Position von A05:2021 bei mit achtunddreißig zugeordneten CWEs. Die Kategorie adressiert Szenarien, wo Benutzer-bereitgestellte Daten nicht ordnungsgemäß validiert, gefiltert oder sanitiert werden, bevor sie in Interpretern verwendet werden.

Konsolidierung von Server-Side Request Forgery in Broken Access Control

Die Konsolidierung von A10:2021 Server-Side Request Forgery in A01:2025 Broken Access Control reflektiert verbessertes Verständnis der SSRF-Anfälligkeit-Mechanik. SSRF-Anfälligkeit stellt grundsätzlich einen Fehler dar, zu kontrollieren, welche Ressourcen ein Server im Namen von Benutzern zugreifen kann – ein Zugriffskontroll-Fehler.

Organisatorische Implikationen

Die kumulative Wirkung der 2025er Änderungen signalisiert eine breitere Verschiebung hin zur Integration von Sicherheit durch den gesamten Software-Entwicklungs-Lebenszyklus. Die Erhöhung von Software Supply Chain Failures betont, dass Organisationen Build-Infrastruktur und Entwickler-Workstations so intensiv sichern müssen wie Produktionssysteme. Die Einführung von Mishandling of Exceptional Conditions reflektiert Anerkennung, dass Fehlerbehandlung eine Kern-Sicherheitskontrolle ist. Der Aufstieg von Security Misconfiguration betont, dass operative Härtung mit schneller Evolution von Cloud-Plattformen Schritt halten muss.

OWASP empfiehlt Organisationen, klare Sicherheits-Programm-Grundlagen zu etablieren, Sicherheit in existierende Entwicklungs- und operative Prozesse zu integrieren, umfassende Sicherheits-Bildungs-Programme zu implementieren und Senior-Stakeholder Sichtbarkeit in Anwendungssicherheits-Programm-Gesundheit durch Metriken-basierte Entscheidungsfindung zu bieten.

Für Entwicklungs-Teams erfordert das 2025er Framework sichere Gestaltung und Threat-Modeling-Praktiken vor dem Schreiben von Code, strukturierte Exception-Behandlung über alle kritischen Flows und umfassende Tests von Supply-Chain-Integritäts-Mechanismen. Für Sicherheits-Teams erfordert das Framework, dass Assessment-Ansätze sich über traditionelle Source-Code-Review hinaus zu Supply-Chain-Komponenten-Analyse und CI/CD-Pipeline-Sicherheits-Validierung erstrecken. Für Organisationen zeigt das Framework an, dass aussagekräftiger Sicherheits-Fortschritt funktionsübergreifende Zusammenarbeit erfordert.


Quellen & Referenzen


Mit Hilfe von KI zusammengefasst.