OWASP Top 10 für Entwickler: Die häufigsten Schwachstellen vermeiden

Was die OWASP Top 10 sind

Die OWASP Top 10 sind eine Liste der zehn kritischsten Sicherheitsrisiken für Webanwendungen, herausgegeben von der Open Worldwide Application Security Project (OWASP) Foundation. Die Liste wird alle paar Jahre aktualisiert und basiert auf der Analyse tausender realer Schwachstellen in Webanwendungen weltweit.

Die aktuelle Version (2021) unterscheidet sich in mehreren Punkten von der Vorgängerversion (2017). Einige Kategorien wurden zusammengefasst, neue kamen hinzu, und die Reihenfolge hat sich geändert. Injection, jahrelang auf Platz 1, ist auf Platz 3 gerutscht, während Broken Access Control auf Platz 1 vorgerückt ist, weil es in der Praxis das häufigste Problem darstellt.

Die OWASP Top 10 sind kein Standard im formalen Sinne, aber sie werden von regulatorischen Rahmenwerken (PCI DSS, NIS2-Umsetzungsempfehlungen) und Sicherheitsstandards (ISO 27001, NIST) als Referenz herangezogen. Wenn du Webanwendungen entwickelst, wird jeder Auditor und Penetrationstester die OWASP Top 10 als Prüfgrundlage verwenden.

A01: Broken Access Control

Broken Access Control ist das mit Abstand häufigste Sicherheitsrisiko in Webanwendungen. Es tritt auf, wenn Benutzer Aktionen ausführen oder auf Daten zugreifen können, die außerhalb ihrer Berechtigungen liegen.

Typische Ausprägungen

Insecure Direct Object References (IDOR): Die URL /api/users/42/profile zeigt das Profil von Benutzer 42. Was passiert, wenn du die 42 durch 43 ersetzt? Wenn die Anwendung die ID aus der URL nimmt und ohne Berechtigungsprüfung die Daten zurückgibt, kann jeder authentifizierte Benutzer die Profile aller anderen einsehen.

Fehlende Funktionslevel-Prüfung: Die Admin-Oberfläche ist nur für Administratoren sichtbar (das Menü wird ausgeblendet). Aber der API-Endpunkt /api/admin/users prüft nicht, ob der aufrufende Benutzer tatsächlich ein Administrator ist. Ein normaler Benutzer, der die URL kennt, hat vollen Zugriff.

Manipulation von Metadaten: Ein Benutzer sendet ein JSON-Objekt an den Server und fügt ein Feld "role": "admin" hinzu, das die Anwendung blind übernimmt und den Benutzer zum Administrator macht (Mass Assignment).

Prävention

Prüfe Zugriffsrechte serverseitig bei jedem Request. Vertraue nie dem Frontend, den Cookies oder den Headern allein. Implementiere eine zentrale Autorisierungslogik, die in jeder Controller-Methode oder Middleware aufgerufen wird. Verwende UUIDs statt sequenzieller IDs für Ressourcen (erschwert das Erraten gültiger IDs). Implementiere Row-Level-Security: Jede Datenbankabfrage filtert nach dem aktuell angemeldeten Benutzer. Teste Autorisierung explizit: Für jede API-Route sollte ein Test prüfen, ob ein nicht autorisierter Benutzer abgewiesen wird.

A02: Cryptographic Failures

Diese Kategorie (früher "Sensitive Data Exposure") umfasst alle Schwachstellen, die durch fehlende, fehlerhafte oder veraltete Verschlüsselung entstehen.

Typische Ausprägungen

Klartext-Speicherung von Passwörtern: Passwörter werden als MD5- oder SHA1-Hash in der Datenbank gespeichert. Beide Algorithmen sind nicht für Passwort-Hashing gedacht und lassen sich mit modernen GPUs in Sekunden brechen.

Fehlende Transportverschlüsselung: Die Anwendung ist über HTTPS erreichbar, aber interne API-Aufrufe zwischen Microservices laufen über HTTP. Ein Angreifer im selben Netzwerk kann den Traffic mitlesen.

Veraltete Verschlüsselungsprotokolle: Die Anwendung unterstützt noch TLS 1.0 oder TLS 1.1 oder verwendet unsichere Cipher Suites.

Prävention

Verwende für Passwort-Hashing ausschließlich speziell dafür entwickelte Algorithmen: bcrypt, scrypt oder Argon2id. Die zugehörige Kryptografie-Richtlinie definiert, welche Algorithmen und Schlüssellängen im Unternehmen zugelassen sind. SHA-256 ist kein Passwort-Hashing-Algorithmus. Erzwinge HTTPS überall, auch intern. Nutze HSTS-Header. Verwende TLS 1.2 oder höher und deaktiviere veraltete Protokolle. Speichere keine sensiblen Daten, die du nicht brauchst. Wenn du eine Kreditkartennummer nicht langfristig speichern musst, speichere sie nicht. Verwende für Verschlüsselung etablierte Bibliotheken (libsodium, OpenSSL) und implementiere nie eigene Kryptografie.

A03: Injection

Injection-Schwachstellen treten auf, wenn Benutzereingaben als Code oder Befehle interpretiert werden. Die bekannteste Form ist SQL Injection, aber auch OS Command Injection, LDAP Injection und NoSQL Injection fallen in diese Kategorie.

Wie SQL Injection funktioniert

Eine verwundbare Abfrage sieht so aus: query = "SELECT * FROM users WHERE name = '" + userInput + "'". Wenn der Benutzer als Eingabe ' OR '1'='1 eingibt, wird die Abfrage zu SELECT * FROM users WHERE name = '' OR '1'='1', was alle Benutzer zurückgibt. Mit '; DROP TABLE users; -- kann der Angreifer die gesamte Benutzertabelle löschen.

Prävention

Die Lösung ist einfach und seit Jahrzehnten bekannt: Verwende parametrisierte Queries (Prepared Statements). In jeder modernen Programmiersprache und jedem Framework gibt es dafür Standardmechanismen. In PHP PDO sieht das so aus: $stmt = $pdo->prepare("SELECT * FROM users WHERE name = ?"); $stmt->execute([$userInput]);. Die Benutzereingabe wird als Parameter übergeben und vom Datenbanktreiber automatisch escaped. Es gibt keinen Grund, jemals String-Konkatenation für SQL-Queries zu verwenden.

Für andere Injection-Typen gelten ähnliche Prinzipien: OS-Befehle nie mit Benutzereingaben zusammenbauen (verwende stattdessen explizite Funktionen wie subprocess.run() mit Array-Argumenten), LDAP-Queries parametrisieren und NoSQL-Queries mit den vom Framework bereitgestellten Query-Buildern erstellen.

A04: Insecure Design

Insecure Design ist eine Kategorie, die 2021 neu in die OWASP Top 10 aufgenommen wurde. Sie beschreibt Schwachstellen, die nicht durch fehlerhafte Implementierung, sondern durch fehlendes oder fehlerhaftes Sicherheitsdesign entstehen.

Typische Ausprägungen

Fehlendes Rate Limiting: Die Passwort-Reset-Funktion hat kein Rate Limiting. Ein Angreifer kann automatisiert tausende E-Mail-Adressen ausprobieren, um gültige Konten zu identifizieren, oder den Code per Brute Force erraten.

Fehlende Business-Logic-Validierung: Ein Onlineshop prüft den Preis eines Artikels nur im Frontend. Ein Angreifer sendet einen manipulierten Request mit einem Preis von 0 Euro und erhält den Artikel kostenlos.

Übermäßiges Vertrauen in den Client: Die Anwendung verlässt sich darauf, dass das Frontend bestimmte Validierungen durchführt (z.B. maximale Dateigrößen). Ein Angreifer umgeht das Frontend und sendet direkt an die API.

Prävention

Führe Threat Modeling durch, um Designschwächen zu erkennen, bevor Code geschrieben wird. Validiere alle Geschäftsregeln serverseitig. Implementiere Rate Limiting auf allen sensiblen Endpunkten (Login, Passwort-Reset, API-Aufrufe). Vertraue dem Client nie: Jede Eingabe, jede Berechtigung, jeder Preis wird serverseitig geprüft.

A05: Security Misconfiguration

Sicherheitsfehlkonfigurationen sind die am einfachsten zu vermeidenden, aber am häufigsten vorkommenden Probleme. Sie entstehen, wenn Systeme mit unsicheren Standardeinstellungen betrieben, unnötige Features aktiviert oder Fehlermeldungen zu viele Informationen preisgeben.

Typische Ausprägungen

Standardpasswörter nicht geändert (Datenbank, Admin-Panel, Netzwerkgeräte). Unnötige Dienste oder Ports offen. Detaillierte Fehlermeldungen mit Stack Traces in der Produktion. Directory Listing auf dem Webserver aktiviert. Fehlende HTTP-Security-Header (Content-Security-Policy, X-Frame-Options, X-Content-Type-Options).

Prävention

Erstelle eine Hardening-Checkliste für jede verwendete Technologie. Automatisiere die Konfiguration mit Infrastructure-as-Code (Terraform, Ansible), damit die sichere Konfiguration reproduzierbar ist. Deaktiviere Debug-Modus und detaillierte Fehlermeldungen in der Produktion. Setze alle relevanten HTTP-Security-Header. Scanne regelmäßig auf Fehlkonfigurationen (z.B. mit Mozilla Observatory, securityheaders.com oder Nuclei).

A06: Vulnerable and Outdated Components

Diese Kategorie betrifft die Verwendung von Bibliotheken, Frameworks und anderen Softwarekomponenten mit bekannten Schwachstellen. In modernen Anwendungen besteht ein Großteil des Codes aus Drittbibliotheken, und jede dieser Bibliotheken kann Schwachstellen enthalten.

Prävention

Führe ein Inventar aller verwendeten Bibliotheken und deren Versionen (Software Bill of Materials, SBOM). Nutze automatisierte Dependency-Scanning-Tools (Dependabot, Renovate, Snyk) in deiner CI/CD-Pipeline. Aktualisiere Bibliotheken regelmäßig, nicht nur wenn eine Schwachstelle bekannt wird. Entferne nicht mehr benötigte Bibliotheken. Bevorzuge aktiv gepflegte Bibliotheken mit einer aktiven Community und zeitnahen Sicherheitsupdates.

A07: Identification and Authentication Failures

Schwachstellen in der Authentifizierung und im Session-Management ermöglichen es Angreifern, Identitäten zu übernehmen oder sich als andere Benutzer auszugeben.

Typische Ausprägungen

Schwache Passwortanforderungen (keine Mindestlänge, keine Komplexitätsanforderungen). Kein Schutz gegen Credential Stuffing oder Brute Force. Session-IDs in der URL. Fehlende Session-Invalidierung beim Logout oder nach Passwortänderung. Keine Multi-Faktor-Authentifizierung für privilegierte Accounts.

Prävention

Erzwinge starke Passwörter (mindestens 12 Zeichen) und prüfe gegen bekannte Passwortlisten (Have I Been Pwned API). Implementiere Rate Limiting und Account Lockout gegen Brute Force. Verwende sichere, zufällige Session-IDs mit ausreichender Entropie (mindestens 128 Bit). Setze Session-Cookies mit den Attributen Secure, HttpOnly und SameSite. Invalidiere Sessions beim Logout und nach Passwortänderung. Implementiere MFA für alle Benutzer, mindestens aber für privilegierte Accounts.

A08: Software and Data Integrity Failures

Diese Kategorie umfasst Schwachstellen, bei denen Software oder Daten ohne Integritätsprüfung verarbeitet werden. Das betrifft insbesondere CI/CD-Pipelines, Auto-Update-Mechanismen und die Deserialisierung von Daten.

Typische Ausprägungen

Unsichere Deserialisierung: Die Anwendung deserialisiert Benutzereingaben (z.B. Java-Objekte, PHP-unserialize, Python-pickle) ohne Validierung. Ein Angreifer kann manipulierte Objekte einschleusen, die bei der Deserialisierung beliebigen Code ausführen.

Kompromittierte CI/CD-Pipeline: Ein Angreifer verschafft sich Zugang zur Build-Pipeline und injiziert bösartigen Code, der in die Produktion deployed wird (Supply-Chain-Angriff).

Prävention

Vermeide die Deserialisierung von Benutzereingaben. Wenn nötig, verwende sichere Formate (JSON statt Java-Serialisierung) und validiere die deserialisierten Daten strikt. Signiere Software-Artefakte und verifiziere Signaturen vor dem Deployment. Sichere deine CI/CD-Pipeline (Zugangskontrolle, Code-Signing, Review-Anforderungen für Pipeline-Änderungen). Verwende Subresource Integrity (SRI) für externe JavaScript-Bibliotheken, die du über CDNs einbindest.

A09: Security Logging and Monitoring Failures

Ohne angemessenes Logging und Monitoring bleiben Angriffe unentdeckt. Die durchschnittliche Dwell Time (Zeit zwischen Kompromittierung und Entdeckung) lag 2024 bei über 10 Tagen. Besseres Monitoring verkürzt diese Zeit erheblich.

Prävention

Logge sicherheitsrelevante Ereignisse: Login-Versuche (erfolgreich und fehlgeschlagen), Zugriffsversuche auf geschützte Ressourcen, Änderungen an Benutzerrechten und Konfigurationen, Fehler und Exceptions. Speichere Logs zentral und schütze sie vor Manipulation. Implementiere Alerting für verdächtige Muster (z.B. viele fehlgeschlagene Login-Versuche von einer IP, Zugriff auf Admin-Funktionen durch einen normalen Benutzer). Logge keine sensiblen Daten (Passwörter, Kreditkartennummern, personenbezogene Daten) in Klartext.

A10: Server-Side Request Forgery (SSRF)

SSRF tritt auf, wenn eine Anwendung HTTP-Requests an eine vom Benutzer kontrollierte URL sendet, ohne die URL zu validieren. Ein Angreifer kann die Anwendung dazu bringen, Requests an interne Systeme zu senden, die von außen nicht erreichbar sind.

Typische Ausprägungen

Eine Funktion zum Importieren von Bildern per URL: Der Benutzer gibt http://169.254.169.254/latest/meta-data/iam/security-credentials/ ein (AWS-Metadaten-Endpunkt) und erhält die IAM-Zugangsdaten des Servers.

Prävention

Validiere und sanitisiere alle URLs, die von Benutzern stammen. Verwende eine Allowlist für erlaubte Domains oder IP-Bereiche. Blockiere Requests an private IP-Bereiche (10.x.x.x, 172.16-31.x.x, 192.168.x.x, 127.x.x.x, 169.254.x.x). Deaktiviere HTTP-Redirects oder validiere die Ziel-URL nach jedem Redirect erneut. Nutze Netzwerksegmentierung, um den Server in ein Segment zu stellen, aus dem er nur die nötigen externen Ziele erreichen kann.

OWASP Top 10 und automatisierte Erkennung

Nicht alle OWASP-Top-10-Schwachstellen lassen sich gleich gut automatisiert erkennen. SAST-Tools (SonarQube, Semgrep, CodeQL) sind gut darin, Injection-Schwachstellen (A03), Cryptographic Failures (A02, z.B. schwache Algorithmen) und Security Misconfiguration (A05, z.B. Debug-Modus aktiviert) zu finden. DAST-Tools (OWASP ZAP, Burp Suite) sind gut darin, Security Misconfiguration (A05, z.B. fehlende HTTP-Header), Authentication Failures (A07, z.B. fehlende Rate-Limiting-Header) und SSRF (A10) zu erkennen.

Schwer automatisiert erkennbar sind Broken Access Control (A01, weil die Autorisierungslogik anwendungsspezifisch ist), Insecure Design (A04, weil es um architekturelle Entscheidungen geht, die kein Scanner bewerten kann) und Software and Data Integrity Failures (A08, weil Supply-Chain-Angriffe oft keine erkennbaren Code-Muster hinterlassen).

Für diese schwer erkennbaren Kategorien brauchst du manuelle Reviews: Code Reviews mit Fokus auf Autorisierung, Threat Modeling für Designentscheidungen und Penetrationstests für die Validierung der Gesamtanwendung.

Die OWASP Top 10 in regulatorischen Rahmenwerken

Die OWASP Top 10 werden in zahlreichen regulatorischen Rahmenwerken und Standards als Referenz herangezogen. PCI DSS (Payment Card Industry Data Security Standard) verweist explizit auf die OWASP Top 10 als Grundlage für die Anforderungen an sichere Anwendungsentwicklung. ISO 27001 Annex A, Kontrolle A.8.28 (Secure coding), fordert, dass sichere Programmierprinzipien angewendet werden. Die OWASP Top 10 sind die am weitesten verbreitete Konkretisierung dieser Anforderung. NIS2 fordert sichere Entwicklungspraktiken, und die OWASP Top 10 werden in den Umsetzungsempfehlungen als Orientierung genannt.

Wenn du nachweisen musst, dass du sichere Entwicklungspraktiken anwendest, sind die OWASP Top 10 die Referenz, auf die sich Auditoren und Prüfer stützen. Dokumentiere, welche Maßnahmen du gegen jede der zehn Kategorien ergriffen hast, und du hast einen soliden Nachweis. In ISMS Lite lassen sich Secure-Coding-Richtlinien und die OWASP-Top-10-Gegenmaßnahmen mit den zugehörigen Controls verknüpfen und für Audits aufbereiten.

Schulung und Awareness im Entwicklungsteam

Die OWASP Top 10 sind auch ein hervorragendes Schulungsinstrument. Eine initiale Schulung von 4 bis 8 Stunden, in der jede Kategorie mit Praxisbeispielen und Übungen durchgegangen wird, gibt dem gesamten Team eine gemeinsame Wissensbasis.

Ergänze die initiale Schulung durch regelmäßige Auffrischungen: Ein kurzer Vortrag (15-30 Minuten) pro Sprint oder Monat zu einer konkreten Schwachstellenklasse oder einem aktuellen Sicherheitsvorfall. Verwende dabei reale Beispiele aus Bug-Bounty-Reports, HackerOne-Veröffentlichungen oder Sicherheitsadvisories von Bibliotheken, die dein Team verwendet. Das ist deutlich wirkungsvoller als abstrakte Theorie.

Hands-on-Übungen erhöhen den Lerneffekt. Plattformen wie OWASP WebGoat, HackTheBox oder PortSwigger Web Security Academy bieten kostenlose Übungsumgebungen, in denen Entwickler Schwachstellen ausnutzen und verstehen können, warum bestimmte Programmiermuster gefährlich sind.

Von der Theorie zur Praxis

Die OWASP Top 10 sind kein Hexenwerk. Die meisten Schwachstellen lassen sich durch wenige grundlegende Praktiken vermeiden: Jede Eingabe validieren, Zugriffsrechte serverseitig prüfen, parametrisierte Queries verwenden, aktuelle Bibliotheken nutzen, sichere Standardkonfigurationen verwenden und sicherheitsrelevante Ereignisse loggen.

Wenn du diese sechs Punkte konsequent umsetzt, hast du bereits den Großteil der OWASP Top 10 abgedeckt. Die automatisierten Tools (SAST, DAST, Dependency Scanning) finden den Rest. Und für die logischen Schwachstellen, die kein Tool findet, gibt es Threat Modeling und Code Reviews.

Weiterführende Artikel

• Secure Development Lifecycle (SDL): Sicherheit in den Entwicklungsprozess einbauen
• API-Sicherheit: Authentifizierung, Rate Limiting und Input Validation
• Dependency Scanning: Schwachstellen in Drittbibliotheken finden
• Schwachstellenmanagement aufbauen: Vom Scan zur Behebung
• Secrets Management: Passwörter, API-Keys und Zertifikate sicher verwalten