OWASP Top 10 2025: Die kritischsten Web-Schwachstellen und ihre Behebung
Die OWASP Top 10 sind der globale Standard für Web-Applikations-Sicherheit. Dieser Artikel erklärt alle 10 Kategorien mit konkreten Code-Beispielen, realen Angriffsfällen und Gegenmaßnahmen für Entwickler und Sicherheitsverantwortliche.
Vincent Heinen Abteilungsleiter Offensive Services TL;DR
Die OWASP Top 10
Diese Zusammenfassung wurde KI-gestützt erstellt (EU AI Act Art. 52).
Inhaltsverzeichnis (11 Abschnitte)
Die OWASP Top 10 sind das bekannteste Sicherheitsdokument der Welt für Web-Applikationen. Das Open Web Application Security Project (OWASP) veröffentlicht alle 3-4 Jahre eine aktualisierte Liste der kritischsten Schwachstellenkategorien - basierend auf echten Daten aus Tausenden Web-Applikations-Pentests.
Jede seriöse Compliance-Anforderung die Web-Sicherheit adressiert - PCI DSS, BSI IT-Grundschutz, ISO 27001 - referenziert OWASP. Wenn Sie wissen wollen ob Ihre Web-Applikation sicher ist, sind die OWASP Top 10 der Startpunkt.
A01: Broken Access Control - Häufigste Schwachstelle
Was es ist: Nutzer können auf Ressourcen oder Funktionen zugreifen, für die sie keine Berechtigung haben.
Real-World-Beispiel: Facebook, 2018 - Access Control Fehler erlaubte jedem Nutzer Fotos anderer Nutzer herunterzuladen, auch wenn diese privat eingestellt waren. 6,8 Millionen Nutzer betroffen.
Typischer Code-Fehler:
// GET /api/documents/:id - kein Check ob Dokument dem User gehört
app.get('/api/documents/:id', authenticate, async (req, res) => {
const doc = await Document.findById(req.params.id);
res.json(doc); // Jeder angemeldete User kann JEDES Dokument lesen!
});Sichere Variante:
app.get('/api/documents/:id', authenticate, async (req, res) => {
const doc = await Document.findOne({
_id: req.params.id,
owner: req.user.id // Eigentümercheck!
});
if (!doc) return res.status(403).json({ error: 'Not found or unauthorized' });
res.json(doc);
});Praxis-Tipp: Jeden API-Endpunkt mit der Frage testen: “Was passiert wenn ein anderer eingeloggter User die ID eines anderen Users ändert?”
A02: Cryptographic Failures - Daten unzureichend geschützt
Was es ist: Sensitive Daten werden nicht oder zu schwach verschlüsselt.
Real-World-Beispiel: LinkedIn 2012 - 117 Millionen Passwort-Hashes gestohlen. Ohne Salt mit SHA-1 gehasht → 90% in Stunden geknackt.
Falsch:
import hashlib
# SHA1 ohne Salt - crack-bar in Sekunden mit Rainbow Tables
password_hash = hashlib.sha1(password.encode()).hexdigest()Richtig:
import bcrypt
# bcrypt mit automatischem Salt, Work Factor 12
password_hash = bcrypt.hashpw(password.encode('utf-8'), bcrypt.gensalt(rounds=12))
# Alternativ (OWASP empfohlen): Argon2id
from argon2 import PasswordHasher
ph = PasswordHasher(time_cost=3, memory_cost=65536, parallelism=4)
hash = ph.hash(password)Weitere Maßnahmen:
- TLS 1.3 für alle Verbindungen (kein TLS 1.0/1.1)
- Festplattenverschlüsselung für Datenbankserver
- Keine sensitiven Daten in Logs, URLs oder Browser-History
A03: Injection - Angreifer injizieren Code
Was es ist: User-Input wird ohne ausreichende Validierung in Interpreter-Befehle eingebettet.
SQL Injection - Klassiker der Web-Sicherheit:
URL: https://example.com/user?id=1' OR '1'='1
Query: SELECT * FROM users WHERE id = '1' OR '1'='1'
→ Gibt ALLE Nutzer zurück!NoSQL Injection (MongoDB):
// Unsicher:
db.users.findOne({
username: req.body.username,
password: req.body.password // Angreifer sendet: { "$ne": null }
})
// → Kein Passwort nötig!
// Sicher: Schema-Validierung erzwingen
const schema = Joi.object({ username: Joi.string(), password: Joi.string() });
const { error, value } = schema.validate(req.body);Immer Parameterized Queries verwenden:
# SQLite - IMMER so:
cursor.execute("SELECT * FROM users WHERE username = ?", (username,))
# NIEMALS:
cursor.execute(f"SELECT * FROM users WHERE username = '{username}'")A04: Insecure Design - Sicherheit in der Architektur
Was es ist: Grundlegende Designentscheidungen die Sicherheit unmöglich machen.
Beispiel: Rate Limiting fehlt auf Login-Endpoint → Brute Force mit 10.000 Versuchen/Sekunde möglich.
Threat Modeling (STRIDE) schon beim Design:
Für jeden neuen Feature fragen:
S: Kann jemand sich als anderer User ausgeben? (Spoofing)
T: Können Daten manipuliert werden? (Tampering)
R: Können Aktionen abgestritten werden? (Repudiation)
I: Können Daten gelesen werden? (Information Disclosure)
D: Kann der Dienst gestört werden? (Denial of Service)
E: Können Rechte eskaliert werden? (Elevation of Privilege)A05: Security Misconfiguration - Falsche Standardeinstellungen
Was es ist: Default-Konfigurationen die unsicher sind.
Häufigste Fehler:
# FALSCH (nginx):
server_tokens on; # Zeigt nginx-Version - gibt Angreifern Infos
# RICHTIG:
server_tokens off;
add_header X-Frame-Options "DENY";
add_header X-Content-Type-Options "nosniff";
add_header Referrer-Policy "strict-origin-when-cross-origin";
# FALSCH: Debug-Modus in Produktion
DEBUG = True # Django
NODE_ENV = 'development' # Node.js
# Richtig: Alle sensitiven Features in Produktion deaktivierenA06: Vulnerable and Outdated Components - Log4Shell lässt grüßen
Was es ist: Third-Party-Libraries mit bekannten CVEs.
Praxis-Maßnahmen:
# Wöchentliche Checks in CI/CD:
npm audit --audit-level=high # Node.js
pip-audit # Python
./gradlew dependencyCheckAnalyze # Java
# Automatische PRs für Updates:
# GitHub Dependabot oder Renovate Bot konfigurierenLog4Shell war vermeidbar wenn SCA in der Pipeline aktiv gewesen wäre - CVE-Datenbank hatte die Schwachstelle am Tag der Veröffentlichung.
A07: Identification and Authentication Failures
Was es ist: Schwachstellen in Authentifizierung und Session Management.
JWT Sicherheitsfalle:
// GEFÄHRLICH: Algorithmus nicht explizit angegeben
jwt.verify(token, secret) // "none" Algorithmus könnte akzeptiert werden!
// SICHER:
jwt.verify(token, secret, { algorithms: ['HS256'] })Session-Management:
// Cookie Security:
res.cookie('session', token, {
httpOnly: true, // Kein JavaScript-Zugriff (XSS-Schutz)
secure: true, // Nur HTTPS
sameSite: 'Strict', // CSRF-Schutz
maxAge: 3600000 // 1 Stunde (kein "niemals ablaufen")
});A08: Software and Data Integrity Failures - Supply Chain
Was es ist: Keine Integritätsprüfung von Software-Updates und CI/CD-Pipelines.
Subresource Integrity für CDN:
<!-- Ohne SRI: CDN-Kompromittierung = XSS auf Ihrer Seite -->
<script src="https://cdn.example.com/jquery.min.js"></script>
<!-- Mit SRI: Hash-Prüfung -->
<script src="https://cdn.example.com/jquery.min.js"
integrity="sha384-hash..."
crossorigin="anonymous"></script>Signed Commits in Git:
git config --global commit.gpgsign true
git commit -m "Feature: Add payment module"
# Commit ist kryptographisch signiert → Manipulation erkennbarA09: Security Logging and Monitoring Failures
Was es ist: Angriffe werden nicht erkannt weil Logging fehlt.
Was mindestens geloggt werden muss:
# Erfolgreiche und fehlgeschlagene Logins
logger.info("LOGIN_SUCCESS", extra={"user_id": user.id, "ip": request.remote_addr})
logger.warning("LOGIN_FAILURE", extra={"username": username, "ip": request.remote_addr})
# Admin-Aktionen (Wer hat Was verändert?)
logger.info("ADMIN_ACTION", extra={
"actor": current_user.id,
"action": "USER_DELETED",
"target_user": user_id,
"timestamp": datetime.utcnow().isoformat()
})
# NIEMALS loggen:
# - Passwörter (auch nicht gehashte)
# - Session-Tokens
# - Vollständige KreditkartennummernA10: Server-Side Request Forgery (SSRF)
Was es ist: Server wird als Proxy missbraucht um auf interne Ressourcen zuzugreifen.
Gefährlichstes Target: Cloud Metadata Service:
POST /api/fetch
{"url": "http://169.254.169.254/latest/meta-data/iam/security-credentials/"}
# → AWS IAM Credentials des Servers werden zurückgegeben!Schutz:
import ipaddress
from urllib.parse import urlparse
ALLOWED_DOMAINS = {"api.approved-partner.com", "cdn.company.de"}
def validate_url(url: str) -> bool:
parsed = urlparse(url)
if parsed.scheme not in ("http", "https"):
return False
# Cloud-Metadata-Adressen blockieren
blocked_ips = [
ipaddress.ip_network("169.254.169.254/32"), # AWS/Azure/GCP Metadata
ipaddress.ip_network("10.0.0.0/8"), # Private IPs
ipaddress.ip_network("192.168.0.0/16"),
]
# Allowlist nutzen statt Blocklist
return parsed.hostname in ALLOWED_DOMAINSOWASP Top 10 im Pentest-Kontext
Bei jedem AWARE7-Web-Applikations-Penetrationstest werden alle OWASP Top 10-Kategorien systematisch geprüft - nach dem OWASP Web Security Testing Guide (WSTG). Das Ergebnis ist ein Bericht mit:
- CVSS v3.1 Score für jede Schwachstelle
- Proof-of-Concept der ausnutzbaren Schwachstellen
- Reproduzierbare Schritte für Ihre Entwickler
- Priorisierte Handlungsempfehlungen
- Option auf Re-Test nach Behebung
PCI DSS 6.4 und BSI CON.10 fordern explizit OWASP-basierte Tests für Web-Applikationen.
Sie möchten wissen ob Ihre Web-Applikation die OWASP Top 10 besteht? In einem Web-Applikations-Penetrationstest prüfen wir systematisch alle Kategorien und liefern einen klaren Bericht mit priorisierten Maßnahmen.
Monatlicher Threat Report
Chris Wojzechowski bewertet einmal im Monat die aktuelle Bedrohungslage aus Sicht eines Informationssicherheitsexperten. Sein 30-köpfiges Team ist näher an realen Cyberbedrohungen dran als kaum jemand sonst — mit konkreten Handlungsempfehlungen, die Sie am nächsten Morgen umsetzen können.
Bestseller-Autor (Wiley-VCH) · M.Sc. Internet-Sicherheit · Bekannt aus Handelsblatt & WamS
Zuletzt behandelt
1x im Monat · Kein Spam · Jederzeit abbestellbar · Datenschutz
Nächster Schritt
Unsere zertifizierten Sicherheitsexperten beraten Sie zu den Themen aus diesem Artikel — unverbindlich und kostenlos.
Kostenlos · 30 Minuten · Unverbindlich
