OWASP Top 10 2025: Was sich geändert hat und warum es wichtig ist

Die OWASP Foundation hat die achte Edition ihrer einflussreichen „Top 10 Security Risks"-Liste für 2025 veröffentlicht und führt bedeutende Änderungen ein, die die sich entwickelnde Landschaft der Applikationssicherheit widerspiegeln. Basierend auf der Analyse von mehr als 175.000 Common Vulnerabilities and Exposures (CVEs) und Feedback von Security-Praktikern weltweit adressiert dieses Update moderne Angriffsvektoren. Im Folgenden wird erläutert, was sich geändert hat, warum diese Änderungen wichtig sind und wie Systeme geschützt werden können.

💡 Am 10. Februar hat GitLab auf der Transcend gezeigt, wie Agentic AI Software Delivery transformiert – mit Kunden-Einblicken und Impulsen zur Modernisierung. Mehr erfahren.

Was ist neu in 2025?

Die Verschiebung von 2021 (als die Liste zuletzt erschien) zu 2025 stellt mehr als kleine Anpassungen dar – es ist ein fundamentaler Wandel in der Applikationssicherheit. Zwei vollständig neue Kategorien wurden in die Liste aufgenommen und eine Kategorie in eine andere konsolidiert, was aufkommende Risiken hervorhebt, die traditionelle Tests oft übersehen.

Diese Ergänzungen und Verschiebungen sind in der folgenden Grafik zu sehen:

Zwei neue Kategorien

• A03: Software Supply Chain Failures: Erweitert die 2021-Kategorie „Vulnerable and Outdated Components" um die gesamte Software-Supply-Chain, einschließlich Dependencies, Build-Systeme und Distributions-Infrastruktur. Trotz der geringsten Vorkommen in Testdaten hat diese Kategorie die höchsten durchschnittlichen Exploit- und Impact-Scores aus CVEs.
• A10: Mishandling of Exceptional Conditions: Fokussiert auf fehlerhafte Error-Behandlung, logische Fehler und Failing-Open-Szenarien. Diese Kategorie adressiert, wie Systeme auf abnormale Bedingungen reagieren.

Wesentliche Ranking-Änderungen

• Security Misconfiguration stieg von #5 (2021) auf #2 (2025) und betrifft nun 3 % der getesteten Applikationen.
• Server-Side Request Forgery (SSRF) wurde in A01: Broken Access Control konsolidiert.
• Cryptographic Failures fielen von #2 auf #4.
• Injection fiel von #3 auf #5.
• Insecure Design verschob sich von #4 auf #6.

Warum diese Änderungen vorgenommen wurden

Die OWASP-Methodik kombiniert datengetriebene Analyse mit Community-Einblicken. Die 2025-Edition analysierte 589 Common Weakness Enumerations (CWEs) – eine substanzielle Steigerung gegenüber den etwa 400 CWEs in 2021. Diese Erweiterung reflektiert die wachsende Komplexität moderner Software-Systeme und die Notwendigkeit, aufkommende Bedrohungen zu erfassen.

Die Community-Survey-Komponente adressiert eine fundamentale Einschränkung: Testdaten schauen im Wesentlichen in die Vergangenheit. Bis Security-Forschende Testmethoden entwickeln und in automatisierte Tools integrieren, können Jahre vergangen sein. Die beiden community-voted Kategorien stellen sicher, dass aufkommende Risiken, die von Praktikern an vorderster Front identifiziert wurden, eingeschlossen werden – selbst wenn sie noch nicht in automatisierten Testdaten verbreitet sind.

Der Anstieg von Security Misconfiguration hebt einen Branchentrend zur konfigurationsbasierten Sicherheit hervor, während Software Supply Chain Failures den Anstieg ausgefeilter Angriffe auf kompromittierte Packages widerspiegelt.

GitLab Ultimate für Vulnerability-Detection und -Management nutzen

GitLab Ultimate bietet umfassendes Security-Scanning zur Erkennung von Risiken über alle OWASP-Top-10-2025-Kategorien hinweg. Die End-to-End-Plattform analysiert Quellcode, Dependencies und Infrastrukturdefinitionen von Projekten. Advanced Static Application Security Testing (SAST) erkennt Injection-Schwachstellen, Cryptographic Failures und unsichere Design-Patterns im Quellcode. Infrastructure as Code (IaC) Scanning findet Security-Fehlkonfigurationen in Deployment-Definitionen. Secret Detection verhindert das Leaken von Credentials, und Dependency Scanning deckt Bibliotheken mit bekannten Schwachstellen in der Software-Supply-Chain auf – und adressiert damit direkt die neue A03-Kategorie für Software Supply Chain Failures.

Darüber hinaus:

• Dynamic Application Security Testing (DAST) testet die deployten Applikationen auf Broken Access Control, Authentication Failures und Injection-Schwachstellen durch Simulation von Angriffsvektoren.
• API Security Testing prüft API-Endpoints auf Input-Validation-Schwächen und Authentication-Bypasses.
• Web API Fuzz Testing deckt auf, wie Applikationen mit Ausnahmebedingungen umgehen, indem unerwartete Inputs generiert werden – und adressiert damit direkt die neue A10-Kategorie für Mishandling of Exceptional Conditions.

Security-Scanning integriert sich nahtlos in die CI/CD-Pipeline und läuft beim Push von einem Feature-Branch, sodass Entwicklungsteams Schwachstellen beheben können, bevor sie Production erreichen. Security-Ergebnisse werden im Vulnerability Report konsolidiert, wo Security-Teams triagieren, analysieren und die Behebung nachverfolgen können. GitLab ermöglicht außerdem den Einsatz von KI-Agents wie dem Security Analyst Agent in der GitLab Duo Agent Platform, um die kritischsten Schwachstellen und die erforderlichen Maßnahmen schnell zu identifizieren.

Zusätzliche Kontrollen lassen sich über Merge-Request-Approval-Policies und Pipeline-Execution-Policies durchsetzen, um sicherzustellen, dass Security-Scanning konsistent in der gesamten Organisation ausgeführt wird. Customer-Success- und Professional-Services-Teams bei GitLab unterstützen dabei, den Wert einer GitLab-Investition zeitnah zu realisieren.

Sichere Software mit Security-Testing in derselben Plattform bereitstellen, die Entwicklungsteams bereits nutzen. Mehr dazu auf der Application Security Testing Solutions-Seite.

Die OWASP Top 10 2025: Vollständige Aufschlüsselung

A01: Broken Access Control

Was es ist

Fehler bei der Durchsetzung von Richtlinien, die verhindern, dass Nutzende außerhalb ihrer vorgesehenen Berechtigungen handeln – was zu unbefugtem Zugriff führt.

Auswirkungen auf das System

• Unbefugte Informationsoffenlegung
• Vollständige Datenzerstörung oder -modifikation
• Privilege Escalation (Nutzende erlangen Admin-Rechte)
• Einsehen oder Bearbeiten der Accounts anderer Nutzender
• API-Zugriff von nicht autorisierten oder nicht vertrauenswürdigen Quellen

Relevante CWEs

• CWE-22: Path Traversal
• CWE-200: Exposure of Sensitive Information to an Unauthorized Actor
• CWE-352: Cross-Site Request Forgery (CSRF)

A02: Security Misconfiguration

Was es ist

Systeme, Applikationen oder Cloud-Services, die aus Security-Perspektive fehlerhaft konfiguriert sind.

Auswirkungen auf das System

• Offenlegung sensibler Informationen durch Fehlermeldungen
• Unbefugter Zugriff über Default-Accounts
• Unnötige Services oder Features aktiviert
• Veraltete Security-Patches
• Server sendet keine Security-Header oder -Direktiven

Relevante CWEs

• CWE-16: Configuration
• CWE-521: Weak Password Requirements
• CWE-798: Use of Hard-coded Credentials

A03: Software Supply Chain Failures

Was es ist

Ausfälle oder Kompromittierungen beim Erstellen, Verteilen oder Aktualisieren von Software – durch Schwachstellen oder böswillige Änderungen in Dependencies, Tools oder Build-Prozessen.

Auswirkungen auf das System

• Kompromittierte Packages, die Backdoors einschleusen
• Schädlicher Code, der während Build-Prozessen injiziert wird
• Verwundbare Dependencies, die sich durch die Applikation kaskadieren
• Nutzung von Komponenten aus nicht vertrauenswürdigen Quellen in Production
• Änderungen in der Supply Chain werden nicht nachverfolgt

Relevante CWEs

• CWE-1395: Dependency on Vulnerable Third-Party Component
• CWE-1104: Use of Unmaintained Third Party Components

A04: Cryptographic Failures

Was es ist

Fehler im Zusammenhang mit fehlender Kryptographie, unzureichend starker Kryptographie, Leaking von kryptographischen Schlüsseln und verwandten Fehlern.

Auswirkungen auf das System

• Offenlegung sensibler Daten (Passwörter, Kreditkarten, Gesundheitsdaten)
• Man-in-the-Middle-Angriffe
• Datenpanne durch schwache Verschlüsselung
• Schlüssel-Kompromittierung mit systemweiter Exposition
• Verstoß gegen regulatorische Compliance-Anforderungen (DSGVO, PCI DSS)

Relevante CWEs

• CWE-327: Use of a Broken or Risky Cryptographic Algorithm
• CWE-330: Use of Insufficiently Random Values

A05: Injection

Was es ist

Systemschwachstellen, die es Angreifenden ermöglichen, Schadcode oder -befehle (SQL, NoSQL, OS-Befehle, LDAP usw.) in Programme einzuschleusen.

Auswirkungen auf das System

• Datenverlust oder -korruption durch SQL-Injection
• Vollständige Datenbank-Kompromittierung
• Server-Übernahme durch Command-Injection
• Cross-Site-Scripting-(XSS)-Angriffe
• Informationsoffenlegung
• Denial of Service

Relevante CWEs

• CWE-89: SQL Injection
• CWE-78: OS Command Injection

A06: Insecure Design

Was es ist

Schwächen im Design, die verschiedene Fehler repräsentieren – ausgedrückt als fehlendes oder unwirksames Kontrolldesign. Architekturelle Mängel statt Implementierungs-Bugs.

Auswirkungen auf das System

• Schwache Passwort-Reset-Flows
• Fehlende Autorisierungsschritte
• Fehlerhafte Business-Logik, die Umgehungen ermöglicht
• Unzureichendes Threat Modeling, das blinde Flecken erzeugt
• Design-Patterns, die unter Angriffsszenarien versagen

Relevante CWEs

• CWE-209: Generation of Error Messages Containing Sensitive Information
• CWE-522: Insufficiently Protected Credentials
• CWE-656: Reliance on Security Through Obscurity

A07: Authentication Failures

Was es ist

Schwachstellen, die es Angreifenden ermöglichen, Systeme dazu zu bringen, ungültige oder fehlerhafte Identitäten als legitim zu erkennen.

Auswirkungen auf das System

• Account-Übernahme und Credential Stuffing
• Session Hijacking
• Erfolgreiche Brute-Force-Angriffe
• Ausnutzung schwacher Passwort-Recovery-Mechanismen
• Multi-Faktor-Authentifizierungs-Bypass

Relevante CWEs

• CWE-287: Improper Authentication
• CWE-306: Missing Authentication for Critical Function
• CWE-521: Weak Password Requirements

A08: Software or Data Integrity Failures

Was es ist

Code und Infrastruktur, die nicht verhindern, dass ungültiger oder nicht vertrauenswürdiger Code/Daten als vertrauenswürdig und valide behandelt werden.

Auswirkungen auf das System

• Unsignierte Updates, die Schadcode-Injection ermöglichen
• Insecure Deserialization, die zu Remote Code Execution führt
• CI/CD-Pipeline-Kompromittierung
• Ausnutzung von Auto-Update-Mechanismen
• Manipulierte Software-Artefakte

Relevante CWEs

• CWE-345: Insufficient Verification of Data Authenticity
• CWE-346: Origin Validation Error
• CWE-347: Improper Verification of Cryptographic Signature

A09: Security Logging & Alerting Failures

Was es ist

Unzureichendes Logging und Monitoring mit inadäquatem Alerting, was schnelle Reaktion erschwert.

Auswirkungen auf das System

• Angriffe bleiben über längere Zeiträume unentdeckt
• Breach-Investigation wird unmöglich
• Compliance-Verstöße durch fehlende Audit-Trails
• Verzögerte Incident-Response
• Unfähigkeit, das Ausmaß einer Kompromittierung zu bestimmen

Relevante CWEs

• CWE-117: Improper Output Neutralization for Logs
• CWE-532: Insertion of Sensitive Information into Log File
• CWE-778: Insufficient Logging

A10: Mishandling of Exceptional Conditions

Was es ist

Programme, die ungewöhnliche und unvorhersehbare Situationen nicht verhindern, erkennen und darauf reagieren – was zu Abstürzen, unerwartetem Verhalten oder Schwachstellen führt.

Auswirkungen auf das System

• Informationsoffenlegung durch zu detaillierte Fehlermeldungen
• Denial of Service durch unbehandelte Exceptions
• Zustandskorruption durch fehlerhafte Error-Behandlung
• Ausnutzung von Race Conditions
• Systeme, die bei Fehlern offen statt geschlossen schalten
• Applikationsabstürze, die sensible Daten exponieren

Relevante CWEs

• CWE-248: Uncaught Exception
• CWE-390: Detection of Error Condition Without Action
• CWE-391: Unchecked Error Condition

Best Practices für Prävention und Remediation

GitLab bietet Tools, die nicht nur das schnelle Finden und Beheben von Schwachstellen innerhalb der OWASP Top 10 ermöglichen, sondern auch deren Eintritt in das Production-System verhindern. Durch Befolgen dieser Best Practices lässt sich die Security-Posture verbessern und aufrechterhalten:

Automatisiertes Security-Scanning für alle Repositories

• SAST-Scanning durchführen, um unsichere Design-Patterns wie Klartext-Passwortspeicherung, inadäquates Error-Handling und fehlende Verschlüsselung während Code-Reviews zu erkennen – Design-Fehler werden früh im Entwicklungszyklus aufgefangen.
• Secret Detection durchführen, um Credentials in Konfigurationsdateien, Umgebungsvariablen und Code zu identifizieren – dies verhindert Klartext-Passwortspeicherung und stellt sicher, dass Secrets ordnungsgemäß über GitLab-CI/CD-Variablen mit Masking und Verschlüsselung verwaltet werden.
• DAST-Scanning durchführen, um Broken-Access-Control-Schwachstellen zu erkennen.
• Dependency Scanning durchführen, um Projekt-Dependencies gegen Schwachstellen-Datenbanken zu scannen und bekannte CVEs in direkten und transitiven Dependencies über mehrere Package-Manager (npm, pip, Maven usw.) zu identifizieren.
• Container Scanning durchführen, um Docker-Images auf verwundbare Base-Layer und Packages zu analysieren und die Container-Supply-Chain-Sicherheit vor dem Deployment sicherzustellen.
• IaC-Scanning durchführen, um Infrastruktur-Definitionsdateien auf bekannte Schwachstellen zu prüfen.
• API-Security-Tools nutzen, um Web-APIs vor unbefugtem Zugriff, Missbrauch und Angriffen zu schützen.
• Web API Fuzz Testing durchführen, um Bugs und potenzielle Schwachstellen zu entdecken, die andere QA-Prozesse übersehen könnten.

Die Security-Posture verstehen

• Eine Software Bill of Materials (SBOM) generieren für vollständige Dependency-Transparenz und Compliance-Anforderungen.
• Den Vulnerability Report nutzen, um Schwachstellen über eine konsolidierte Ansicht der im Codebase gefundenen Security-Vulnerabilities zu triagieren.
• Mit detaillierter Remediation-Anleitung und Risk-Assessment-Daten schnell auf Schwachstellen reagieren.
• Security Inventory nutzen, um zu visualisieren, welche Assets geschützt werden müssen und welche Maßnahmen zur Verbesserung der Sicherheit erforderlich sind.
• Compliance Center nutzen, um Compliance-Standards-Adherence-Reporting, Violations-Reporting und Compliance-Frameworks zu verwalten.

Prävention einrichten und Dokumentation pflegen

• Security Policies konfigurieren, um Merges oder Deployments zu blockieren, wenn hochgradig kritische Schwachstellen in Dependencies erkannt werden – Security-Standards werden automatisch durchgesetzt.
• Compliance Frameworks nutzen, um organisationsweite Security-Standards durch automatisierte Policy-Checks durchzusetzen, die Verschlüsselungsanforderungen, Credential-Management-Praktiken und sichere Workflow-Implementierungen verifizieren.
• GitLab Wiki und Repository-Dokumentation nutzen, um Security-Design-Prinzipien, genehmigte Patterns und Architectural Decision Records zu pflegen, die Entwicklungsteams zu Secure-by-Design-Implementierungen anleiten.
• Merge-Request-Approval-Rules implementieren, die ein Security-Architect-Review für Features erfordern, die Authentication, Authorization, Verschlüsselung oder sensible Datenverarbeitung betreffen – so wird Security-Validierung auf Design-Ebene sichergestellt.
• Tests erstellen, um Input-Validation und Allowlist-Ansätze für Dateipfade zu verifizieren.
• GitLab Issues und Epics nutzen, um Security-Anforderungen und Threat Models in der Design-Phase zu dokumentieren – dies schafft eine nachvollziehbare Aufzeichnung von Security-Entscheidungen und stellt sicher, dass Security-Überlegungen vor Implementierungsbeginn adressiert werden.

KI nutzen

• Code Suggestions für proaktive Guidance während der Entwicklung nutzen – mit Vorschlägen für sichere Design-Patterns wie korrektes Password-Hashing (bcrypt, Argon2), verschlüsselte Speichermechanismen und angemessenes Error-Handling, das keine sensiblen Informationen preisgibt.
• Security Analyst Agent nutzen, um erkannte Insecure-Design-Schwachstellen im Kontext zu bewerten – mit Erklärung der architekturellen Implikationen, Risikobewertung basierend auf dem Threat Model der Applikation und Remediation-Strategien, die grundlegende Design-Fehler statt nur Symptome adressieren.
• Code mit KI reviewen lassen, um konsistente Code-Review-Standards im Projekt sicherzustellen.

Kernaussagen für Entwicklungsteams

• Supply-Chain-Sicherheit ist entscheidend: Mit der Aufnahme von A03 und den hohen Impact-Scores ist die Absicherung der Software-Supply-Chain keine Option mehr. SBOM-Tracking, Dependency-Scanning und Integritätsprüfung sollten durchgängig in der Pipeline implementiert werden.
• Konfiguration ist wichtiger denn je: Der Aufstieg auf #2 zeigt, dass konfigurationsbasierte Sicherheit nun ein primärer Angriffsvektor ist. Konfigurationsverifizierung automatisieren und IaC mit integrierter Security implementieren.
• Traditionelle Bedrohungen bestehen fort: Obwohl Injection und Cryptographic Failures im Ranking gefallen sind, bleiben sie kritisch. Die Priorisierung nicht reduzieren, nur weil sie in der Liste gefallen sind.
• Error-Handling ist Security: Die neue A10-Kategorie unterstreicht, dass der Umgang der Applikation mit Fehlern ein Security-Thema ist. Sicheres Error-Handling von Beginn an implementieren.
• Testing muss sich weiterentwickeln: Die erweiterte CWE-Abdeckung (589 vs. 400 in 2021) bedeutet, dass Testing-Strategien umfassend sein müssen. SAST, DAST, Quellcode-Analyse und manuelles Penetration-Testing für effektive Abdeckung kombinieren.

Die GitLab Security and Governance Solutions und die Security-Scanning-Dokumentation bieten weitere Informationen zur Stärkung der Security-Posture.