OWASP Top 10 Übersicht

Was OWASP ist und was die Top 10 sind

OWASP (Open Worldwide Application Security Project) ist eine US-amerikanische Non-Profit-Stiftung, gegründet 2001. Sie veröffentlicht keine bindenden Standards, sondern Industrie-Konsens-Dokumente zu Web-Anwendungs-Sicherheit. Bekannteste Veröffentlichungen:

• Top 10 — die meistzitierte Risiko-Liste, Update alle 3–4 Jahre.
• ASVS (Application Security Verification Standard) — detaillierter Anforderungs-Katalog für sichere Web-Apps.
• Cheat Sheet Series — über 80 prägnante Themen-Spickzettel (XSS, CSRF, Auth, Crypto, etc.).
• Web Security Testing Guide — Test-Methodik für Penetration-Tester:innen.
• Mobile Top 10, API Top 10, LLM Top 10 — spezialisierte Listen.

Die Top 10 wurden zuletzt 2021 und 2025 veröffentlicht. Die Editionen unterscheiden sich teils erheblich — Kategorien wandern in der Rangfolge, neue kommen dazu, alte werden konsolidiert. Wir beziehen uns auf die 2025-Edition, die zum Zeitpunkt dieser Doku die aktuelle ist.

Was die Top 10 sind:

• Eine Risiko-Liste — nicht Häufigkeits-, sondern eine Mischung aus Häufigkeit, Ausnutzbarkeit, Erkennbarkeit und Schadens-Potenzial.
• Eine Awareness-Karte für Entwickler:innen, Manager:innen und Sicherheits-Verantwortliche.
• Eine Referenz für Audits, Compliance-Programme, Verträge.

Was die Top 10 nicht sind:

• Eine vollständige Schwachstellen-Liste. Es gibt Hunderte Schwachstellen-Klassen; die Top 10 wählen die zehn relevantesten.
• Ein Pflicht-Standard mit rechtlicher Bindung. Sie sind freiwillige Industrie-Konvention — werden aber regulatorisch und in Audit-Programmen referenziert (BSI, PCI DSS, NIST).
• Ein Tool für reine Häufigkeits-Statistik. Die Methodik mischt verschiedene Faktoren.

Wie die Top 10 entstehen

Die Methodik kombiniert zwei Datenquellen:

1. CVE- und Vorfall-Daten (8 Kategorien). OWASP wertet öffentliche Daten aus — bug-bounty-Reports, Vorfall-Reports, CVE-Datenbanken, Pentest-Reports. Acht der zehn Kategorien werden über statistische Häufigkeit + Exploit-Aufwand + Erkennbarkeit + Wirkung gewichtet.

2. Community-Survey (2 Kategorien). Zwei der zehn Slots werden über eine Branchen-Umfrage gefüllt — was halten Sicherheits-Profis für derzeit unterschätzt? Dadurch finden auch neue, noch nicht voll in Statistiken sichtbare Risiken Platz (z. B. Insecure Design in 2021, KI-spezifische Themen 2025).

Begriffe in der Liste:

• CWE-Mapping. Jede Top-10-Kategorie ist mit einer oder mehreren CWE-IDs (Common Weakness Enumeration, siehe glossar-und-begriffe) verknüpft. Das macht sie technisch präzise zuordenbar.
• Risiko-Rating pro Kategorie: Exploitability, Detectability, Technical Impact.
• Beispiele und Wie verhindere ich das?-Sektionen pro Kategorie auf der OWASP-Website.

Die Verschiebungen zwischen Editionen sind aufschlussreich:

• 2017 → 2021: „Injection" fiel von Platz 1 auf Platz 3 — nicht weil weniger Injection passiert, sondern weil Access-Control-Probleme statistisch nachgezogen haben.
• 2021 → 2025: Insecure Design hat sich etabliert; Software-Supply-Chain-Themen sind aufgestiegen; KI-spezifische Sub-Kategorien sind hinzugekommen.

A01 — Broken Access Control

Was es ist: Schwächen in der Autorisierungs-Logik: Nutzer:innen können auf Ressourcen zugreifen, die ihnen nicht gehören oder Aktionen ausführen, für die sie keine Berechtigung haben.

Typische Beispiele:

• IDOR (Insecure Direct Object Reference) — URL /api/orders/12345 zeigt fremde Bestellung, wenn Authentifizierung erfolgt, aber Owner-Check fehlt.
• BOLA (Broken Object Level Authorization) — API-Variante des Gleichen, OWASP-API-Top-1.
• Vertikale Privilege Escalation — normale Nutzer:innen schaffen es zu Admin-Rechten.
• Horizontale Privilege Escalation — eine:r kommt an Daten einer anderen Nutzer:in derselben Rechte-Klasse.
• Force-Browsing — geschützte Admin-Seite ist über direkte URL erreichbar, weil nur die Navigation geschützt ist.
• Mass-Assignment — Nutzer:in setzt Felder, die nur Admins setzen dürfen.

Vertieft in dieser Doku:

• Autorisierung-Grundlagen (Kap 15)
• IDOR und BOLA (Kap 15)
• Privilege Escalation (Kap 15)

Warum auf Platz 1: Access-Control-Probleme sind in fast jeder Web-App präsent, oft erst nach Authentifizierung sichtbar, und führen direkt zu Daten-Lecks oder Aktions-Missbrauch. Statistisch der häufigste Erfolgs-Pfad bei Pentests.

A02 — Cryptographic Failures

Was es ist: Schwächen in der Verschlüsselung oder im Krypto-Schlüssel-Management — Daten, die geschützt sein sollten, sind es nicht.

Typische Beispiele:

• Sensitive Daten ohne Verschlüsselung im Transport (HTTP statt HTTPS).
• Schwache Hashing-Algorithmen für Passwörter (MD5, SHA-1, ungesalzte SHA-256 statt argon2id/bcrypt).
• Hartcodierte Schlüssel im Code oder in Repositories.
• Self-Rolled Crypto — eigene Verschlüsselungs-Algorithmen statt geprüfter Libraries.
• Schwache Zufallszahlen (Math.random() statt CSPRNG).
• AES-ECB statt AES-GCM / ChaCha20-Poly1305.
• Fehlende oder schwache TLS-Konfiguration auf Server-Ebene.

Vertieft in dieser Doku:

• Crypto-Grundregeln (Kap 17)
• Hashing (Kap 17)
• Symmetrische Verschlüsselung (Kap 17)
• TLS-Grundlagen Deployment (Kap 19)

Bemerkenswert: Diese Kategorie hieß früher „Sensitive Data Exposure" — Umbenennung 2021, weil der Fokus auf der Ursache (Crypto-Mangel) liegen sollte, nicht auf der Folge (Daten leaken).

A03 — Injection

Was es ist: Eingaben einer Nutzer:in werden ungesichert in einen Interpreter (SQL, Shell, LDAP, XPath, HTML/JS, etc.) übernommen — der Interpreter führt sie als Code aus.

Typische Beispiele:

• SQL-Injection — Eingabe wird unparametrisiert in Query eingebaut.
• NoSQL-Injection — MongoDB-$where, JSON-Operator-Tricks.
• Command Injection — exec() mit String-Konkatenation.
• LDAP-Injection, XPath-Injection — analog.
• OS-Command-Injection über system() / popen() / Runtime.exec().
• CRLF-Injection in HTTP-Headern.
• XSS wird seit OWASP 2021 als Sub-Kategorie von Injection geführt — Eingabe wird als HTML/JS in den Browser injiziert.

Vertieft in dieser Doku:

• Injection-Grundlagen (Kap 13)
• SQL-Injection (Kap 13)
• NoSQL-Injection (Kap 13)
• Command Injection (Kap 13)
• XSS komplett in Kap 11

Warum es immer noch wichtig ist: Injection-Schwachstellen sind seit 1998 dokumentiert und seit 20+ Jahren in jedem Web-Sicherheits-Lehrbuch. Trotzdem treten sie weiter auf — vor allem in Legacy-Code, in ORM-Edge-Cases und in selbstgebauten Such-/Filter-Funktionen. ORM ist kein Garant — Raw-Queries, dynamische Spalten-Namen, ORDER-BY-Manipulation sind klassische Fallen.

---

A04 — Insecure Design

Was es ist: Sicherheits-Probleme, die nicht durch Coding-Fehler entstehen, sondern durch fehlerhaftes Design. Wurde 2021 neu eingeführt und ist eine bewusste Erweiterung der Liste um „Sicherheit-by-Design"-Aspekte.

Typische Beispiele:

• Fehlende Rate-Limits an Login-Endpunkten — Brute Force trivial möglich.
• Klar-Text-Recovery-Tokens in URL-Parametern.
• Authentifizierungs-Logik, die Wiederholungs-Angriffe ermöglicht.
• Vertrauen in Client-seitige Validierung ohne Server-Pendant.
• Unsichere Default-Konfiguration in selbst entwickelten Komponenten.
• Fehlende Bedrohungs-Modellierung in der Entwurfs-Phase.

Vertieft in dieser Doku:

• Bedrohungsmodelle (Kap 1) — das fundamentale Werkzeug
• Risiko und Defense-in-Depth (Kap 1)
• Praxis: viele konkrete Beispiele in den Kapiteln 11–18

Was Insecure Design schwer macht: Du kannst es nicht patchen wie einen Code-Bug. Insecure Design verlangt Architektur-Änderungen, oft Refactorings, manchmal Re-Designs. Genau deshalb ist die Kategorie wichtig: sie zwingt zur Sicherheit von Anfang an, nicht zum Aufkleben am Ende.

A05 — Security Misconfiguration

Was es ist: Fehlkonfigurationen an Anwendung, Framework, Server, Cloud-Plattform oder Datenbank, die Sicherheits-Schwächen erzeugen.

Typische Beispiele:

• Default-Credentials unverändert (admin/admin, root/root).
• Verbose Error Messages mit Stack-Traces in Production.
• Debug-Mode in Production aktiv (Django, Rails, Express).
• Offene Admin-Panels an exponierten URLs.
• Offene S3-Buckets ohne Authentifizierung.
• Fehlende Sicherheits-Header (CSP, HSTS, X-Frame-Options).
• Unnötige Features aktiv (Verzeichnis-Listing, Sample-Apps, Test-Endpunkte).
• Veraltete Cloud-Konfigurationen (Public-Read auf Buckets, offene Security Groups).

Vertieft in dieser Doku:

• Secure Headers Übersicht (Kap 16)
• Reverse-Proxy-Härtung (Kap 20)
• Logging und Audit (Kap 20)

Warum es so häufig ist: Komplexe Software hat viele Konfigurations-Schalter. Defaults wechseln zwischen Versionen, Cloud-Plattformen geben Sicherheits-Verantwortung an Kund:innen weiter („Shared Responsibility"). Eine Fehlkonfiguration ist oft schneller passiert als gefixt — viele Datenlecks der letzten Jahre (offene Elasticsearch-Cluster, offene MongoDB, S3-Buckets) gehören in diese Kategorie.

A06 — Vulnerable and Outdated Components

Was es ist: Anwendung nutzt Komponenten (Libraries, Frameworks, Container-Images), die bekannte Schwachstellen haben oder veraltet sind.

Typische Beispiele:

• npm-Paket mit kritischer CVE, nicht aktualisiert.
• Java-Library Log4j mit Log4Shell-Lücke (CVE-2021-44228) — der prominenteste Fall.
• WordPress-Plugin seit zwei Jahren nicht gewartet.
• Container-Image mit veralteter glibc.
• Frontend-Library (jQuery 1.x) mit XSS-Lücke.

Risiken in der Software-Lieferkette:

• Manipulierte Pakete in Package-Registries (npm event-stream 2018, ua-parser-js 2021, xz Utils 2024).
• Typosquatting — Paket mit ähnlichem Namen wie populäres Paket.
• Compromised Maintainer — legitimer Paket-Maintainer wird übernommen.

Vertieft in dieser Doku:

• Indirect in API- und Backend-Sicherheit (Kap 18)
• Zukünftig in einem dezidierten „Supply Chain Security"-Vertiefungs-Artikel
• CVE-Watch und Patching (Kap 20)

Werkzeuge für Praxis:

• Dependabot / Renovate — automatische Pull Requests für Dependency-Updates.
• npm audit / pip-audit / cargo audit — CLI-Checks.
• Snyk, Sonatype, GitHub Security Advisories — kommerzielle und freie Datenbanken.
• SBOM (Software Bill of Materials) — strukturierter Komponenten-Auszug, zunehmend regulatorisch verlangt (US Executive Order 14028, EU Cyber Resilience Act).

A07 — Identification and Authentication Failures

Was es ist: Schwächen in der Identifikation oder Authentifizierung der Nutzer:innen — von schwachen Passwort-Richtlinien bis zu fehlerhafter Session-Implementierung.

Typische Beispiele:

• Schwache Passwort-Anforderungen (4-stellige PIN bei sensitiven Konten).
• Fehlende Brute-Force-Limits an Login-Endpunkten.
• Credential Stuffing möglich — keine Anti-Automation.
• Klartext-Passwort-Speicherung oder schwaches Hashing.
• Session-Fixation möglich.
• Lange Session-Lebensdauer ohne Re-Authentifizierung.
• JWT mit alg=none akzeptiert.
• OAuth-Redirect-URI nicht validiert.
• Fehlende MFA-Option.

Vertieft in dieser Doku:

• Auth-Grundlagen (Kap 14)
• Passwort-Hashing (Kap 14)
• Session-Cookies (Kap 14)
• JWT Stateless-Tokens (Kap 14)
• OAuth2 und OIDC (Kap 14)
• WebAuthn und Passkeys (Kap 14)

A08 — Software and Data Integrity Failures

Was es ist: Schwächen in den Mechanismen, die Integrität von Software-Updates, kritischen Daten und CI/CD-Pipelines sicherstellen sollen.

Typische Beispiele:

• Unsignierte Software-Updates — Update-Mechanismus prüft keine Signatur, Angreifer schiebt manipulierte Version unter.
• CI/CD-Pipeline-Kompromittierung — Build-Server wird übernommen, schadhafter Code landet im Release.
• Unsichere Deserialization — Java-, PHP-, Python-Objekte aus untrusted Quellen werden deserialisiert, ausführbarer Code injiziert.
• Auto-Update aus unsicheren CDNs — Frontend-Library wird dynamisch nachgeladen, Angreifer manipuliert CDN.
• Fehlende Integrity-Checks bei kritischen Daten (Konfiguration, Lizenzdaten).

Realer Vorfall-Bereich:

• SolarWinds 2020 — Build-Pipeline kompromittiert, schadhafter Code in tausenden Organisationen.
• 3CX 2023 — Software-Update-Mechanismus über kompromittierten Subgraph manipuliert.
• xz-utils 2024 — Supply-Chain-Angriff mit jahrelanger Vorbereitung, in letzter Minute entdeckt.

Vertieft in dieser Doku:

• Aspekte in Secrets im Code (Kap 18)
• Vorab-Konzept: Crypto-Grundregeln — Signatur und Code-Signing (Kap 17)
• Zukünftiges Vertiefungs-Thema: dezidierter Supply-Chain-Artikel

Frameworks und Standards:

• SLSA (Supply-Chain Levels for Software Artifacts) — Google-getriebenes Framework für Build-Integrität.
• Sigstore — kostenfreie Code-Signing-Infrastruktur für Open Source.
• In-toto, SBOMs, attestations — gehören zu diesem Themenfeld.

---

A09 — Security Logging and Monitoring Failures

Was es ist: Fehlende oder unzureichende Logs und Alarmierung — Angriffe werden nicht erkannt, oder erst Wochen/Monate später.

Typische Beispiele:

• Keine Logs für Auth-Events (Login-Erfolg, -Fehler, Passwort-Wechsel).
• Logs ohne Korrelations-IDs — Vorfälle nicht nachvollziehbar.
• Logs nur lokal, gehen bei Geräte-Kompromittierung verloren.
• Verbose Logs mit PII — eigenes Datenschutz-Problem.
• Keine Alerts bei Anomalien (Login-Spike, Massen-Export, neue Admin-Rolle).
• Logs nie ausgewertet — manche Vorfälle sind in Logs, niemand schaut.

Vertieft in dieser Doku:

• Logging und Audit (Kap 20)
• SIEM und Detektion (Kap 20)
• Incident-Response-Grundlagen (Kap 20)

Warum es so oft schiefgeht: Logs sind „unsichtbare Sicherheit" — sie wirken erst im Vorfall. Im Alltag werden sie wegoptimiert (Speicher-Kosten), Alerts werden ausgeschaltet (zu laut), Retention wird verkürzt (Datenschutz-Argument). Im Ernstfall fehlt dann das Material für die Aufklärung. Forensik nach Vorfall braucht zuverlässige Logs aus den letzten 90 bis 180 Tagen.

A10 — Server-Side Request Forgery (SSRF)

Was es ist: Anwendung lässt sich dazu bringen, HTTP-Anfragen im Namen des Servers an interne oder beliebige externe Ziele zu schicken. Insbesondere in Cloud-Umgebungen gefährlich.

Typische Beispiele:

• Webhook-Konfiguration nimmt URL entgegen — Angreifer lässt Server http://169.254.169.254/latest/meta-data/ aufrufen (AWS-Metadata-Endpoint) und greift Cloud-Credentials ab.
• PDF-zu-HTML-Service lädt externe Bilder — Angreifer lässt internes Admin-Panel laden, bekommt Inhalt im PDF zurück.
• Mail-Server mit URL-Preview lädt Phishing-Pixel — Angreifer enumeriert interne Services.
• Image-Resize-Service mit User-Upload-URL.

Vertieft in dieser Doku:

• SSRF und Cloud-Metadata (Kap 18)

Warum es 2021 neu in der Liste war: SSRF war jahrelang als Sub-Kategorie geführt. Mit dem Cloud-Boom — und dem dramatischen Capital-One-Vorfall 2019 (100 Mio. Datensätze über SSRF + AWS-Metadata-Endpoint) — wurde klar, dass SSRF eine eigene Kategorie verdient.

Schutz-Pattern:

• Allowlist statt Blocklist für ausgehende URLs.
• IMDSv2 in AWS (Token-basierte Metadata-Abfrage statt offener Endpoint).
• VPC-Endpoint-Architektur für sensitive Cloud-APIs.
• DNS-Rebinding-Schutz im URL-Validator.

Wie du die Top 10 in der Praxis nutzt

Drei Wege:

1. Als Awareness-Karte für Teams. Bei Onboarding neuer Entwickler:innen, in Security-Trainings, in Code-Review-Checklisten. Die zehn Kategorien sind kompakt genug, um sie ohne Spezial-Wissen zu vermitteln, und decken die wichtigsten Risiken ab.

2. Als Test-Plan für Pentests und Code-Reviews. Pentest-Anbieter und interne Security-Teams nutzen die Top 10 als Mindest-Test-Umfang. „Wir haben gegen OWASP Top 10 getestet" ist ein verbreiteter Audit-Maßstab. Vorsicht: das ist Minimum, nicht Endpunkt.

3. Als Brücke zu ASVS für reifere Programme. Wenn die Top 10 ausgereizt sind, kommt der ASVS ins Spiel — ein 280-Anforderungen-Katalog in drei Reifegrad-Stufen. Banken, Versicherungen, kritische Infrastruktur arbeiten oft mit ASVS-Level 2 oder 3 als Mindeststandard.

Was die Top 10 nicht ersetzt:

• Bedrohungs-Modellierung — eine spezifische Karte für dein System, nicht eine generische Liste.
• ASVS / NIST 800-53 / BSI IT-Grundschutz — für Compliance-Programme.
• Pentest-Berichte — finden Konkretes statt Kategorisches.
• Bug Bounty — kontinuierlicher Security-Feedback-Kanal.

Die Top 10 sind ein Startpunkt, kein vollständiges Programm.

Verwandte OWASP-Listen

Neben den Web-Top-10 gibt es für spezialisierte Domänen eigene Listen:

Für deine Web-App ist die Web-Top-10 die Standard-Referenz. Wer eine REST-API hat, sollte zusätzlich die API-Top-10 lesen — manche Risiken (BOLA, Excessive Data Exposure, Lack of Rate Limiting) sind dort schärfer formuliert.

Wie diese Doku die Top 10 abdeckt

Wenn du nach Kategorie lernen willst: starte hier und springe zum vertiefenden Kapitel. Wenn du nach Anwendungs-Schicht lernen willst (Frontend, Backend, Crypto, API, Deployment): folge der Kapitel-Reihenfolge von 11 bis 20.

Interessantes

Die Top 10 sind keine Test-Checkliste

OWASP betont selbst: die Top 10 sind Awareness-Dokument, kein Test-Standard. Wer „compliant zu OWASP Top 10" behauptet, ohne den Kontext zu verstehen, baut auf Sand. Echte Test-Standards sind ASVS, Web Security Testing Guide, NIST SP 800-53.

2017er Edition als historische Quelle

Die 2017er Top 10 enthielten noch separat „XSS" und „CSRF". 2021 wurden beide konsolidiert (XSS als Sub-Kategorie von Injection; CSRF aus der Liste entfernt, weil moderne Framework-Defaults es weitgehend lösen). Wer Texte und Audits aus dieser Zeit liest, sollte die Übersetzungs-Tabelle kennen.

Stakeholder-Verteilung der Survey-Daten

OWASP zieht die Survey-Daten aus einer Mischung von Penetration-Testern, Code-Reviewern, Bug-Bounty-Forschenden, Defense-Engineers. Die Verteilung der Teilnehmer-Profile entscheidet, welche Kategorien in den Survey-Slots landen. 2021 war die Verteilung gut dokumentiert; 2025 ähnlich.

ASVS als nächster Schritt

Wer die Top 10 verinnerlicht hat, wechselt zum Application Security Verification Standard. ASVS ist deutlich detaillierter — Level 1 ist Web-Pflicht-Standard, Level 2 für Anwendungen mit sensitive Daten, Level 3 für hochkritische Systeme (Banken, Gesundheit, Defence). 280+ Anforderungen statt 10 Kategorien.

OWASP und Regulierung

BSI-IT-Grundschutz, PCI-DSS, ISO 27001, NIS2 referenzieren OWASP-Ressourcen indirekt. Bei Compliance-Audits kommt fast immer eine Frage nach „Wie testet ihr gegen OWASP Top 10?". Die Antwort sollte mehr enthalten als „wir kennen die Liste".

Why-Frame statt Was-Frame

Eine reife Sicherheits-Kultur fragt nicht „Welche A0x-Kategorie ist das?", sondern „Welche Annahmen sind hier brüchig?". Die Top 10 sind ein Werkzeug, kein Selbstzweck. Wer in Architektur-Reviews nur Top-10-Bingo spielt, verpasst die strukturelle Frage.

Generative KI: was die Top 10 nicht abdecken

Klassische OWASP Top 10 deckt LLM-spezifische Risiken (Prompt Injection, Datenvergiftung, Model-Theft) nicht ab. Dafür gibt es die separate OWASP LLM Top 10. Wer KI-Anwendungen baut, sollte beide Listen lesen.

Weiterführende Ressourcen

Externe Quellen

• OWASP Top 10 – Aktuelle Edition
• OWASP ASVS
• OWASP API Security Top 10
• OWASP Mobile Top 10
• OWASP LLM Top 10
• OWASP Cheat Sheet Series
• OWASP Web Security Testing Guide
• MITRE CWE Top 25
• SLSA – Supply-chain Levels for Software Artifacts
• BSI IT-Grundschutz

Verwandte Artikel

• Was ist Web-Sicherheit?
• Bedrohungsmodelle
• Risiko und Defense-in-Depth
• Glossar und Begriffe
• XSS-Grundlagen (Kap 11)
• CSRF-Grundlagen (Kap 12)
• Injection-Grundlagen (Kap 13)
• Auth-Grundlagen (Kap 14)
• Autorisierung-Grundlagen (Kap 15)
• Secure Headers Übersicht (Kap 16)
• Crypto-Grundregeln (Kap 17)
• API-Bedrohungen (Kap 18)
• TLS-Grundlagen Deployment (Kap 19)
• Reverse-Proxy-Härtung (Kap 20)