Die OWASP Top 10 sind der bekannteste Standard für Sicherheitsrisiken bei Webanwendungen. Ob Entwickler, Security Engineer oder Führungskraft — dieser Leitfaden erklärt jede Kategorie anhand von Praxisbeispielen, Erkennungstechniken und Behebungsstrategien.
Ein regelmäßig aktualisiertes Dokument zur Sensibilisierung, das die kritischsten Sicherheitsrisiken für Webanwendungen einstuft. Es basiert auf Datenanalysen von Hunderten Organisationen, Community-Umfragen und realen Daten zu Sicherheitsverletzungen. Es wird von PCI DSS, DORA, NIS2 und zahlreichen Branchenstandards referenziert.
Die häufigste Schwachstelle — in 94 % der getesteten Anwendungen gefunden.
/api/users/123/profile in /api/users/124/profile/admin/dashboard zuZuvor „Offenlegung sensibler Daten“ — umbenannt, um die eigentliche Ursache hervorzuheben.
HTTPS überall mit HSTS erzwingen. AES-256, bcrypt/Argon2 und SHA-256+ verwenden. Geheimnisse niemals fest codieren — Vault oder AWS Secrets Manager verwenden. Ruhende Daten verschlüsseln. TLS 1.0/1.1 deaktivieren.
Die klassische Webschwachstelle — auch nach zwei Jahrzehnten noch unter den Top 3.
' OR 1=1 -- und weitaus ausgefeiltere AngriffeParametrisierte Abfragen für alle Datenbankinteraktionen. Eingabevalidierung mit Positivlisten. Kontextgerechte Ausgabecodierung. Content-Security-Policy-Header. Datenbankkonten nach dem Prinzip der geringsten Rechte. ORMs konsequent verwenden.
Neue Kategorie — Fehler auf Designebene, keine Implementierungsfehler.
Behebung: Bedrohungsmodellierung (STRIDE, PASTA) in die Designphase integrieren. Sichere Designmuster verwenden. Missbrauchsszenarien parallel zu Anwendungsfällen definieren.
In 90 % der getesteten Anwendungen gefunden.
Wiederholbaren Härtungsprozess etablieren. Alle unnötigen Funktionen entfernen. Sämtliche Sicherheitsheader implementieren. Konfigurationsverwaltung mit IaC automatisieren. Regelmäßige Konfigurationsprüfungen durchführen. CSPM für die Cloud verwenden.
Behebung: Komponentenbestand pflegen (SBOM). CVE-Datenbanken kontinuierlich überwachen. Nicht verwendete Abhängigkeiten entfernen. Aktualisierungen mit Dependabot/Renovate automatisieren.
MFA implementieren. Starke Passwörter erzwingen und sie mit Datenbanken kompromittierter Zugangsdaten abgleichen. Ratenbegrenzung für Authentifizierungsendpunkte. Sichere Sitzungsverwaltung (zufällige IDs, HTTPOnly-/Secure-Flags). Sitzungen bei Abmeldung oder Passwortänderung invalidieren.
Behebung: Digitale Signaturen für sämtliche Software und Daten. Subresource Integrity (SRI) für externe Ressourcen. CI/CD durch Zugriffskontrollen und Signierung absichern. Unsichere Deserialisierung vermeiden — JSON verwenden.
Durchschnittliche Zeit bis zur Erkennung einer Sicherheitsverletzung: 204 Tage (IBM 2024). Ohne angemessene Protokollierung können Angreifer dauerhaften Zugriff etablieren, Daten exfiltrieren und ihre Position ausbauen — ohne dabei Alarme auszulösen.
Behebung: Alle Authentifizierungsereignisse, Fehler bei der Zugriffskontrolle und Fehler bei der Eingabevalidierung protokollieren. Kontext einbeziehen (Zeitstempel, Benutzer, IP, Aktion). Protokolle zentral in einem manipulationsgeschützten SIEM speichern. Automatisierte Alarmierung implementieren. Erkennungsfähigkeiten regelmäßig testen.
Neue Kategorie — aufgrund der zunehmenden Verbreitung in Cloud-nativen Architekturen hinzugefügt.
http://169.254.169.254/, um IAM-Zugangsdaten zu erlangenAlle von Benutzern bereitgestellten URLs serverseitig validieren. Positivlisten für zulässige Domains verwenden. Private IP-Bereiche blockieren (10.x, 172.16.x, 169.254.x, 127.x). Nicht benötigte URL-Schemata deaktivieren (file://, gopher://). IMDSv2 auf AWS verwenden. Dienste zum Abrufen von URLs segmentieren.
| OWASP-Kategorie | KENSAI-Abdeckung |
|---|---|
| A01 Fehlerhafte Zugriffskontrolle | IDOR-Tests, Umgehung der Autorisierung, CORS-Prüfungen |
| A02 Kryptografische Fehler | TLS-Analyse, Header-Prüfungen, Überprüfung der Verschlüsselung |
| A03 Injection | SQL, XSS, Befehlsinjektion, SSTI, Header-Injection |
| A04 Unsicheres Design | Ratenbegrenzung, vorhersagbare Ressourcen, Logiktests |
| A05 Sicherheitsfehlkonfiguration | Header, Standardeinstellungen, Offenlegung von Informationen, HTTP-Methoden |
| A06 Verwundbare Komponenten | Technologie-Fingerprinting, Datenbank mit mehr als 332.000 CVE |
| A07 Authentifizierungsfehler | Standardzugangsdaten, Sitzungstests, Cookie-Analyse |
| A08 Integritätsfehler | SRI-Prüfungen, Deserialisierungstests |
| A09 Protokollierungsfehler | Analyse von Sicherheitsheadern, Überprüfung der Fehlerbehandlung |
| A10 SSRF | Injektion interner Endpunkte, Tests von Cloud-Metadaten |
Kostenloser Scan — unverbindlich und ohne Kreditkarte. AI-gestütztes DAST mit Compliance-konformer Berichterstattung.
Kostenlosen Scan starten →Fehlerhafte Zugriffskontrolle (A01) — in 94 % der getesteten Anwendungen gefunden. Sie rückte von Platz 5 auf Platz 1 vor und verdeutlicht das weitverbreitete Versagen bei der Durchsetzung von Autorisierung, insbesondere in APIs und SPAs.
Die OWASP Top 10 selbst sind freiwillig. Sie werden jedoch von PCI DSS (fordert die Berücksichtigung der OWASP Top 10), NIS2 (erwartet ein systematisches Schwachstellenmanagement), DORA (verweist auf branchenübliche Tests) und zahlreichen Anbieterbewertungen referenziert. In der Praxis sind sie damit faktisch verpflichtend.
Automatisierte DAST-Tools erkennen die meisten Kategorien effektiv — insbesondere Injection (A03), kryptografische Fehler (A02), Fehlkonfigurationen (A05) und verwundbare Komponenten (A06). Einige Kategorien wie unsicheres Design (A04) und Protokollierungsfehler (A09) erfordern häufig eine manuelle Bewertung. Nutzen Sie automatisierte Scans für eine breite Abdeckung und manuelle Tests für die Tiefe.
Alle 3–4 Jahre. Wichtige Veröffentlichungen: 2013, 2017, 2021. Jede Aktualisierung spiegelt Veränderungen der Bedrohungslandschaft wider — mit der Aktualisierung von 2021 wurden unsicheres Design (A04) und SSRF (A10) eingeführt und andere Kategorien neu geordnet.
Sicherheit ist nicht optional.
🗡️ Das KENSAI-Team