Die OWASP Top Ten 2025 bringen entscheidende Neuerungen mit sich – nicht nur in der Nomenklatur, sondern vor allem bei der Gewichtung aktueller Bedrohungen. Insbesondere die wachsenden Risiken entlang der Software-Lieferketten fordern Entwickler zu einem Umdenken in Architektur und Ablauf ihrer Projekte. In diesem Artikel analysieren wir die aktualisierte Risikoliste und zeigen, wie Entwicklungs-Teams frühzeitig effektive Sicherheitsmechanismen verankern können.
Was ist die OWASP Top Ten?
Seit 2003 listet das Open Worldwide Application Security Project (OWASP) regelmäßig die zehn kritischsten Risiken für Webanwendungen. Die OWASP Top Ten ist ein international anerkanntes Referenzdokument für Entwickler, Sicherheitsexperten und Entscheidungsträger. Sie fungiert als Basis für Schulungen, Risikoanalysen und Compliance-Vorgaben – und wird alle drei Jahre aktualisiert. Die Version 2025 basiert auf weltweiten Daten aus öffentlich gemeldeten Sicherheitsvorfällen, Community-Feedback und Sicherheitstools.
Was hat sich 2025 geändert? – Ein Überblick
Die neue Ausgabe der OWASP Top Ten 2025 zeigt eine deutliche Verschiebung: Neben klassischen Risiken wie Injection oder fehlerhafter Authentifizierung rücken erstmals Angriffe auf die Software-Lieferkette und Paketabhängigkeiten ins Zentrum. Besonders auffällig ist die zunehmende Priorisierung von Supply Chain Security – ein Thema, das durch Angriffe wie auf SolarWinds (2020) oder 3CX (2023) globale mediale Aufmerksamkeit erhielt.
Hier eine Zusammenfassung der Top Ten 2025 im Vergleich zu 2021:
- A01: Broken Access Control – bleibt führend, da über 94 % getesteter Anwendungen entsprechende Schwachstellen aufweisen (OWASP Daten, 2025).
- A02: Cryptographic Failures – Nachfolger des früheren ‚Sensitive Data Exposure‘, betont die Wichtigkeit korrekter Verschlüsselungsverfahren.
- A03: Injection – inklusive SQL-, NoSQL-, OS- und LDAP-Injections.
- A04: Insecure Design – betont das Risiko unzureichender Sicherheitsarchitektur in frühen Phasen.
- A05: Security Misconfiguration – nach wie vor häufig, von offenen S3-Buckets bis zu Standard-Credentials.
- A06: Vulnerable and Outdated Components – stark verknüpft mit dem neuen Fokus auf Software-Lieferketten.
- A07: Identification and Authentication Failures – inklusive unsicherer Logins, Passwort-Rücksetzung usw.
- A08: Software and Data Integrity Failures – NEU: Beinhaltet Schwächen in CI/CD-Systemen, Manipulation von Deployment-Artefakten und Supply-Chain-Angriffe.
- A09: Security Logging and Monitoring Failures – für effektives Incident Response Management unerlässlich.
- A10: Server-Side Request Forgery (SSRF) – erstmals in der Top Ten, durch stark zunehmende Angriffe auf interne Ressourcen via Cloud/API-Konnektoren.
Fokus: Software Supply Chain Security (A08)
Ein bemerkenswerter Neuzugang in der Liste ist der Punkt Software and Data Integrity Failures. Dieser Risikofaktor adressiert Schwächen in der Software-Lieferkette – insbesondere Angriffsvektoren über CI/CD-Pipelines, Paketmanager (z. B. npm, PyPI), Skripts und veraltete Abhängigkeiten. Laut einer Studie von Sonatype aus dem Jahr 2024 ist die Zahl der bekannten Supply-Chain-Angriffe gegenüber 2020 um 742 % gestiegen.
Das Problem: Entwickler verlassen sich routinemäßig auf externe Bibliotheken und Tools. Doch jedes unüberwachte oder kompromittierte Artefakt kann zur Eintrittspforte für Angreifer werden. Prominentestes Beispiel bleibt der SolarWinds-Hack, bei dem über manipulierte Build-Systeme 33.000 Kunden kompromittiert wurden – darunter Großunternehmen und Regierungsstellen.
Security by Design stärken – neue Prioritäten für Dev-Teams
Die Neuaufnahme von Insecure Design als eigenständiger Risikofaktor (A04) unterstreicht die Bedeutung einer frühzeitigen Einbettung von Sicherheit in Softwareprojekte. Code Security ist nicht länger ein reines QA-Thema – Anforderungen an Integrität, Authentifizierung und Datenschutz müssen bereits im Architekturentwurf gedacht werden.
Eine Umsetzung von „Security by Design“ setzt voraus:
- Einbeziehung von Sicherheitsexperten in der Planungsphase jedes Projekts.
- Durchführung von Bedrohungsanalysen und Abuse-Case-Diskussionen vor dem ersten Commit.
- Nutzung sicherer Patterns und Frameworks, etwa durch das STRIDE-Modell oder OWASP ASVS (Application Security Verification Standard).
Ein gutes Beispiel liefert GitHub: Seit 2023 bewertet das Tool Dependabot nicht mehr nur Updates, sondern hebt auch das Sicherheitsrisiko veralteter Dependencies hervor – eine direkt aus der OWASP A06-Klassifikation entlehnte Praktik.
Prävention statt Reaktion: Sicherheitsmaßnahmen früh implementieren
Ein zentraler Punkt der neuen OWASP-Ausgabe ist die Forderung nach Frühintervention. Je später eine Schwachstelle entdeckt wird, desto teurer wird ihre Behebung – laut IBM Security (2023) liegt der durchschnittliche Schaden pro Datenvorfall inzwischen bei 4,45 Mio. US-Dollar. Frühzeitige Erkennung ist daher nicht nur sicherer, sondern auch wirtschaftlicher.
Zur effektiven Umsetzung in der Praxis empfehlen sich:
- Automatisiertes Security Testing per SAST, DAST und Dependency Scanning in jedem CI/CD-Lauf.
- Verbindliche Security-Gates in der Pipeline für Builds und Deployments.
- Schulung und Awareness-Programme für Entwickler und Produktverantwortliche (z. B. via OWASP Juice Shop oder Hacker101).
Zero Trust und Least Privilege auf Anwendungsebene
Angesichts der OWASP-Kategorien A01 (Broken Access Control) und A07 (Identification and Authentication Failures) rückt besonders das Prinzip des Zero Trust in den Fokus. Nur explizit festgelegte, überprüfte Kommunikationswege sollten erlaubt sein, mit einer granularen Rechtevergabe nach dem Modell des „Least Privilege“.
Das bedeutet konkret:
- Einführung stark differenzierter Rollen- und Rechtemodelle auf API- und Webebene.
- Zweifaktor-Authentisierung (2FA) als Standard für privilegierte Benutzerkonten.
- Session Management nach Best Practices: sichere Token, Short-Lived Sessions, csrf-Schutz.
2024 kam es laut Verizon Data Breach Investigations Report (DBIR) bei 74 % aller Hacking-Vorfälle zu einer Ausnutzung fehlerhafter oder gestohlener Anmeldeinformationen – ein klarer Beleg für die Priorität starker Authentifizierungs- und Autorisierungslogik.
Tipps zur Integration der OWASP-Empfehlungen in die Entwicklung
Viele Teams kämpfen mit der Integration von Sicherheitsrichtlinien in agile Abläufe. Sicherheit sollte jedoch kein „Add-on“, sondern Teil des DevSecOps-Workflows sein. Hier einige erprobte Ansätze aus der Praxis:
- Sichere Coding-Guidelines etablieren und versionieren – z. B. mit Hilfe der Secure Coding Guidelines von OWASP oder der BSI-Kompaktreihe.
- Security Champions in Entwicklerteams benennen, die regelmäßig Know-how vermitteln und Sicherheitsbedenken frühzeitig adressieren.
- Bug Bounty Programme oder Pentesting durch externe Spezialisten mindestens jährlich einplanen.
Fazit: Sicherheit als integraler Bestandteil des Entwicklungszyklus
Die OWASP Top Ten 2025 zeigen klar: Sicherheitsrisiken haben sich weiter diversifiziert – und damit auch die Verantwortung von Entwicklerteams und Organisationen. Ob neue Risiken der Software-Lieferkette oder bewährte Schwachstellen in Authentifizierung und Zugriffskontrolle – wer Webanwendungen sicher gestalten will, muss Sicherheit proaktiv denken, von Anfang an.
Stellen Sie sich den Herausforderungen und teilen Sie Ihre Erfahrungen mit der Community: Welche Tools, Methoden oder Prozesse haben sich in Ihrem Team bewährt? Diskutieren Sie mit uns – auf unserer Plattform oder im nächsten OWASP Chapter Meeting in Ihrer Region. Jetzt ist der richtige Zeitpunkt, Sicherheit neu zu denken.
