OWASP Top 10
Die OWASP Top 10 ist eine alle paar Jahre aktualisierte Liste der kritischsten Sicherheitsrisiken für Webanwendungen, herausgegeben vom Open Web Application Security Project. Sie ist kein Standard im rechtsverbindlichen Sinne, aber de-facto-Referenz für Entwickler, Sicherheitstester und Auditoren weltweit. Wenn eine Webanwendung die OWASP Top 10 berücksichtigt, ist sie gegen die häufigsten und folgenreichsten Angriffe geschützt.
Für FIAE-Azubis ist die OWASP Top 10 prüfungsrelevant: Sie strukturiert das Themenfeld Secure Coding und gibt Orientierung, welche Schwachstellen beim Entwickeln und Code-Review zu beachten sind. Die aktuelle Liste stammt aus dem Jahr 2021 und spiegelt die Realität hunderter analysierter Webanwendungen wider.
1) Die OWASP Top 10 (2021)
Klicke auf einen Eintrag für eine ausführliche Erklärung mit Angreiferbeispiel und Gegenmaßnahmen. Die Farbe zeigt den typischen Schweregrad an – Rot steht für kritisch, Orange für hoch, Gelb für mittel.
OWASP Top 10 – 2021 · Klicke zum Aufklappen
A01
Broken Access Control
Zugriffskontrolle umgehen · von A10 auf #1 gestiegen
Was ist es? Nutzer können auf Ressourcen oder Funktionen zugreifen, für die sie keine Berechtigung haben. Typisch: URL-Manipulation (
Beispiel: Ein Nutzer ändert in der URL
Schutz: Server-seitige Autorisierungsprüfung für jede Anfrage. Deny-by-Default. Objektreferenzen nicht direkt aus IDs ableiten (GUID verwenden oder Ownership prüfen). Mehr in Autorisierung nach dem Login.
/admin aufrufen ohne Admin zu sein), Insecure Direct Object References (IDOR: /rechnung?id=1234 auf fremde Rechnungen ändern).Beispiel: Ein Nutzer ändert in der URL
/api/orders/1001 die ID auf 1002 und sieht die Bestellung eines anderen Kunden. Die API prüft nicht, ob die bestellte Ressource dem eingeloggten Nutzer gehört.Schutz: Server-seitige Autorisierungsprüfung für jede Anfrage. Deny-by-Default. Objektreferenzen nicht direkt aus IDs ableiten (GUID verwenden oder Ownership prüfen). Mehr in Autorisierung nach dem Login.
Häufigkeit
94%
A02
Cryptographic Failures
Schwache oder fehlende Verschlüsselung · früher: Sensitive Data Exposure
Was ist es? Sensible Daten werden unzureichend verschlüsselt oder im Klartext übertragen/gespeichert. Passwörter mit MD5 gehashed, HTTP statt HTTPS, veraltete TLS-Versionen, Kryptoschlüssel hart kodiert im Quellcode.
Beispiel: Passwörter mit MD5 ohne Salt gespeichert. Bei einem Datenbankdump kann ein Angreifer in Minuten alle Passwörter via Rainbow-Table cracken.
Schutz: HTTPS überall. Passwörter mit bcrypt/scrypt/Argon2 hashen (nicht MD5/SHA-1). TLS 1.2+ erzwingen. Sensible Daten nur so lange speichern wie nötig. Details: Passwörter richtig hashen.
Beispiel: Passwörter mit MD5 ohne Salt gespeichert. Bei einem Datenbankdump kann ein Angreifer in Minuten alle Passwörter via Rainbow-Table cracken.
Schutz: HTTPS überall. Passwörter mit bcrypt/scrypt/Argon2 hashen (nicht MD5/SHA-1). TLS 1.2+ erzwingen. Sensible Daten nur so lange speichern wie nötig. Details: Passwörter richtig hashen.
Häufigkeit
83%
A03
Injection
SQL-, Command-, LDAP-Injection · war jahrelang #1
Was ist es? Nicht-vertrauenswürdige Nutzereingaben werden als Kommando oder Abfrage interpretiert. Bekannteste Form: SQL-Injection. Auch: Command Injection (OS-Befehle), LDAP-Injection, XML-Injection.
Beispiel: Login-Formular:
Schutz: Prepared Statements / Parameterized Queries. ORM verwenden. Input validieren und sanitizen. Mehr: SQL-Injection, Input-Validierung.
Beispiel: Login-Formular:
' OR '1'='1 als Passwort → SQL wird zu WHERE pw='' OR '1'='1' → immer wahr → Login ohne Passwort.Schutz: Prepared Statements / Parameterized Queries. ORM verwenden. Input validieren und sanitizen. Mehr: SQL-Injection, Input-Validierung.
Häufigkeit
80%
A04
Insecure Design
Fehlerhaftes Sicherheitsdesign · neu in 2021
Was ist es? Sicherheitsprobleme, die durch mangelndes Security-by-Design entstehen – also nicht durch fehlerhafte Implementierung, sondern durch fehlerhafte Architektur. Fehlende Rate-Limiting, keine Sicherheitsanforderungen in User Stories, keine Threat-Modellierung.
Beispiel: Eine Passwort-Reset-Funktion fragt drei „Sicherheitsfragen" ab, die aus öffentlichen sozialen Medien leicht zu beantworten sind. Das ist ein Design-Problem, kein Code-Problem.
Schutz: Threat Modeling. Security-Anforderungen von Anfang an. Secure Design Patterns verwenden. Defense in Depth.
Beispiel: Eine Passwort-Reset-Funktion fragt drei „Sicherheitsfragen" ab, die aus öffentlichen sozialen Medien leicht zu beantworten sind. Das ist ein Design-Problem, kein Code-Problem.
Schutz: Threat Modeling. Security-Anforderungen von Anfang an. Secure Design Patterns verwenden. Defense in Depth.
Häufigkeit
60%
A05
Security Misconfiguration
Fehlkonfiguration · Standard-Passwörter, offene Debug-Seiten
Was ist es? Sicherheitsrelevante Konfigurationen sind falsch oder fehlen: Standard-Passwörter nicht geändert, unnötige Features aktiv, Fehlerseiten mit Stack-Traces, offene Cloud-Storage-Buckets, unnötige HTTP-Methoden erlaubt.
Beispiel: AWS S3 Bucket mit öffentlichem Lesezugriff enthält Kundendaten. „Bequemlichkeit beim Setup" → Datenpanne mit Millionenstrafe.
Schutz: Hardening-Checklisten. Infrastructure as Code mit Security-Scan. Minimalprinzip: nur aktivieren, was gebraucht wird. Security Headers setzen (→ Security Headers).
Beispiel: AWS S3 Bucket mit öffentlichem Lesezugriff enthält Kundendaten. „Bequemlichkeit beim Setup" → Datenpanne mit Millionenstrafe.
Schutz: Hardening-Checklisten. Infrastructure as Code mit Security-Scan. Minimalprinzip: nur aktivieren, was gebraucht wird. Security Headers setzen (→ Security Headers).
Häufigkeit
90%
A06
Vulnerable and Outdated Components
Veraltete Bibliotheken und Abhängigkeiten
Was ist es? Verwendung von Bibliotheken, Frameworks oder Komponenten mit bekannten Schwachstellen (CVEs). Log4Shell (Log4j 2021) ist das bekannteste Beispiel: eine Lücke in einer weit verbreiteten Java-Logging-Bibliothek ermöglichte Remote Code Execution auf Millionen von Systemen.
Schutz: Dependency-Inventar pflegen. Automatisierte Schwachstellenscans (npm audit, Dependabot, Snyk). Zeitnahe Updates. Details: Dependency Management.
Schutz: Dependency-Inventar pflegen. Automatisierte Schwachstellenscans (npm audit, Dependabot, Snyk). Zeitnahe Updates. Details: Dependency Management.
Häufigkeit
70%
A07
Identification and Authentication Failures
Broken Authentication · schwache Login-Mechanismen
Was ist es? Schwachstellen in Authentifizierung und Session-Management: fehlende MFA, schwache Passwortrichtlinien, unsichere Passwort-Reset-Flows, Session-IDs in URLs, keine Session-Invalidierung nach Logout.
Beispiel: Session-Token wird nach Logout nicht invalidiert. Angreifer, der das Token aus dem Browser-History oder einem Log kennt, kann sich weiter als der Nutzer ausgeben.
Schutz: MFA implementieren. Starke Session-Token (kryptografisch zufällig, min. 128 Bit). Session bei Logout und nach Inaktivität invalidieren. Details: Broken Authentication.
Beispiel: Session-Token wird nach Logout nicht invalidiert. Angreifer, der das Token aus dem Browser-History oder einem Log kennt, kann sich weiter als der Nutzer ausgeben.
Schutz: MFA implementieren. Starke Session-Token (kryptografisch zufällig, min. 128 Bit). Session bei Logout und nach Inaktivität invalidieren. Details: Broken Authentication.
Häufigkeit
55%
A08
Software and Data Integrity Failures
Supply Chain · unsichere Deserialisierung · neu in 2021
Was ist es? Software oder Daten werden ohne Integritätsprüfung verwendet: unsichere CI/CD-Pipelines, ungeprüfte externe Abhängigkeiten (npm-Pakete), Auto-Update ohne Signaturprüfung, unsichere Deserialisierung.
Beispiel: SolarWinds-Angriff 2020: Angreifer injizierten Schadcode in den Build-Prozess eines Softwareanbieters. Tausende Kunden installierten das kompromittierte Update.
Schutz: Signaturen für Updates prüfen. SBOM (Software Bill of Materials). Secure CI/CD mit Integrity-Checks. Details: Supply Chain Security.
Beispiel: SolarWinds-Angriff 2020: Angreifer injizierten Schadcode in den Build-Prozess eines Softwareanbieters. Tausende Kunden installierten das kompromittierte Update.
Schutz: Signaturen für Updates prüfen. SBOM (Software Bill of Materials). Secure CI/CD mit Integrity-Checks. Details: Supply Chain Security.
Häufigkeit
47%
A09
Security Logging and Monitoring Failures
Fehlende Protokollierung · Angriffe bleiben unentdeckt
Was ist es? Sicherheitsereignisse werden nicht oder unzureichend protokolliert. Angriffe bleiben unentdeckt, weil niemand Logs auswertet oder Alarme konfiguriert sind. Durchschnittliche Erkennungszeit: 207 Tage.
Beispiel: 10.000 fehlgeschlagene Login-Versuche in einer Stunde – aber keine Alarmierung, kein Rate-Limiting. Brute-Force läuft ungestört durch.
Schutz: Login-Ereignisse, Zugriffsverletzungen, Fehler protokollieren. Logs ins SIEM. Alert bei Anomalien. Logs tamper-proof speichern.
Beispiel: 10.000 fehlgeschlagene Login-Versuche in einer Stunde – aber keine Alarmierung, kein Rate-Limiting. Brute-Force läuft ungestört durch.
Schutz: Login-Ereignisse, Zugriffsverletzungen, Fehler protokollieren. Logs ins SIEM. Alert bei Anomalien. Logs tamper-proof speichern.
Häufigkeit
33%
A10
Server-Side Request Forgery (SSRF)
Server wird als Proxy für interne Anfragen missbraucht · neu in 2021
Was ist es? Eine Webanwendung ruft eine URL ab, die der Nutzer bestimmt – ohne zu prüfen, ob die Ziel-URL intern oder extern ist. Angreifer können so interne Systeme (Cloud-Metadata, interne APIs) abfragen, die sonst nicht erreichbar wären.
Beispiel: Funktion „Vorschau einer URL generieren" → Angreifer gibt
Schutz: Allowlist für erlaubte URLs. Netzwerksegmentierung (Server darf keine internen IPs erreichen). URL-Validierung server-seitig.
Beispiel: Funktion „Vorschau einer URL generieren" → Angreifer gibt
http://169.254.169.254/latest/meta-data/ an (AWS Metadata-Endpoint) → erhält IAM-Credentials des Servers.Schutz: Allowlist für erlaubte URLs. Netzwerksegmentierung (Server darf keine internen IPs erreichen). URL-Validierung server-seitig.
Häufigkeit
29%
Die Prozentzahlen geben an, in wie vielen der analysierten Anwendungen diese Kategorie als Schwachstelle identifiziert wurde. Broken Access Control führt mit 94 % – fast jede Webanwendung hat irgendwo eine Zugriffskontrollschwäche.
2) OWASP im Entwicklungsprozess einsetzen
| Phase | OWASP-Einsatz |
|---|---|
| Anforderungen | Security Requirements aus OWASP ASVS (Application Security Verification Standard) ableiten |
| Design | Threat Modeling – Bedrohungen für jede Top-10-Kategorie identifizieren |
| Entwicklung | Secure-Coding-Checklisten; OWASP Cheat Sheet Series als Referenz |
| Testing | OWASP Testing Guide für manuelle Tests; automatisierte Scanner (ZAP, Burp Suite) |
| Betrieb | Monitoring, WAF-Regeln nach OWASP-Kategorien, Incident Response |
Zusammenfassung
Die OWASP Top 10 (2021) listet die häufigsten und gefährlichsten Webanwendungs-Schwachstellen: A01 Broken Access Control, A02 Cryptographic Failures, A03 Injection, A04 Insecure Design, A05 Security Misconfiguration, A06 Outdated Components, A07 Auth Failures, A08 Integrity Failures, A09 Logging Failures, A10 SSRF. Jede Lektion dieses Kurses vertieft einen oder mehrere dieser Punkte: nächste Station ist die detaillierteste Einzelschwachstelle der Liste – SQL-Injection.