OWASP Top 10: Die häufigsten Sicherheitslücken im Web

Webanwendungen sind das Rückgrat moderner Unternehmen – und gleichzeitig eines der beliebtesten Angriffsziele für Cyberkriminelle. Die OWASP Top 10 liefern seit über 20 Jahren eine maßgebliche Übersicht der kritischsten Sicherheitsrisiken im Web. Wer diese Schwachstellen kennt und gezielt absichert, schützt nicht nur seine Anwendung, sondern auch die Daten seiner Nutzer. In diesem Artikel erfährst du, welche Sicherheitslücken aktuell die größte Bedrohung darstellen und wie du sie mit Security Headers, Content Security Policy (CSP) und bewährten Best Practices effektiv entschärfst.

Was ist OWASP und warum sind die Top 10 so wichtig?

Das Open Web Application Security Project (OWASP) ist eine gemeinnützige Organisation, die sich der Verbesserung der Softwaresicherheit verschrieben hat. Die OWASP Top 10 werden regelmäßig aktualisiert und bilden die zehn häufigsten und gefährlichsten Schwachstellenkategorien in Webanwendungen ab. Sie dienen Entwicklern, Security-Teams und Auditoren weltweit als Referenz – und sind in vielen Compliance-Standards wie PCI DSS oder ISO 27001 fest verankert.

Die aktuelle Version (2021) umfasst folgende Kategorien:

1. A01 – Broken Access Control
2. A02 – Cryptographic Failures
3. A03 – Injection
4. A04 – Insecure Design
5. A05 – Security Misconfiguration
6. A06 – Vulnerable and Outdated Components
7. A07 – Identification and Authentication Failures
8. A08 – Software and Data Integrity Failures
9. A09 – Security Logging and Monitoring Failures
10. A10 – Server-Side Request Forgery (SSRF)

Die kritischsten Schwachstellen im Detail

A01 – Broken Access Control

Broken Access Control ist auf Platz 1 aufgestiegen und betrifft über 94 % der getesteten Anwendungen. Das Problem: Nutzer können auf Ressourcen oder Funktionen zugreifen, für die sie keine Berechtigung haben. Ein klassisches Beispiel ist die direkte Manipulation von URLs:

https://example.com/api/users/1234/profile
# Ein Angreifer ändert die ID:
https://example.com/api/users/5678/profile

Gegenmaßnahme: Implementiere serverseitige Autorisierungsprüfungen für jeden Endpunkt. Verlasse dich niemals auf clientseitige Kontrollen.

A03 – Injection

SQL Injection, NoSQL Injection und Command Injection bleiben eine ernste Bedrohung. Ein verwundbarer Code sieht häufig so aus:

# UNSICHER – niemals so implementieren!
query = "SELECT * FROM users WHERE username = '" + user_input + "'"

# SICHER – Prepared Statements verwenden
cursor.execute("SELECT * FROM users WHERE username = %s", (user_input,))

Nutze grundsätzlich Prepared Statements oder ORM-Frameworks, um Injection-Angriffe zu unterbinden.

A05 – Security Misconfiguration

Fehlkonfigurationen gehören zu den häufigsten Ursachen für Sicherheitsvorfälle. Dazu zählen offene Cloud-Storage-Buckets, Standard-Passwörter, aktivierte Debug-Modi oder fehlende Security Headers. Gerade letztere sind ein einfacher, aber wirkungsvoller Hebel für mehr Web-Sicherheit.

Security Headers richtig konfigurieren

Security Headers sind HTTP-Antwortheader, die den Browser anweisen, bestimmte Sicherheitsrichtlinien durchzusetzen. Sie schützen vor einer Vielzahl von Angriffen wie Cross-Site Scripting (XSS), Clickjacking und MIME-Sniffing.

Nginx-Konfiguration

server {
    listen 443 ssl http2;
    server_name example.com;

    # Verhindert Clickjacking
    add_header X-Frame-Options "DENY" always;

    # Verhindert MIME-Type-Sniffing
    add_header X-Content-Type-Options "nosniff" always;

    # Aktiviert XSS-Filter (Legacy-Browser)
    add_header X-XSS-Protection "1; mode=block" always;

    # Erzwingt HTTPS für 1 Jahr
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;

    # Kontrolliert Referrer-Informationen
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;

    # Beschränkt Browser-Features
    add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
}

Apache-Konfiguration

<IfModule mod_headers.c>
    Header always set X-Frame-Options "DENY"
    Header always set X-Content-Type-Options "nosniff"
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
</IfModule>

Security Headers testen

Nach der Konfiguration solltest du deine Header unbedingt validieren:

# Header prüfen mit curl
curl -I https://example.com

# Alternativ: Mit dem securityheaders.com-Scanner
# https://securityheaders.com/?q=example.com

Content Security Policy (CSP) – Der Schutzschild gegen XSS

Die Content Security Policy ist einer der mächtigsten Security Headers und verdient besondere Aufmerksamkeit. Eine CSP definiert, aus welchen Quellen der Browser Ressourcen laden darf – Skripte, Stylesheets, Bilder, Fonts und mehr.

Eine praxistaugliche CSP erstellen

Beginne mit einer restriktiven Policy und lockere sie schrittweise:

# Strikte CSP für eine typische Webanwendung
add_header Content-Security-Policy "
    default-src 'self';
    script-src 'self' 'nonce-RandomValue123';
    style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
    font-src 'self' https://fonts.gstatic.com;
    img-src 'self' data: https://cdn.example.com;
    connect-src 'self' https://api.example.com;
    frame-ancestors 'none';
    base-uri 'self';
    form-action 'self';
" always;

CSP im Report-Only-Modus testen

Bevor du eine CSP scharf schaltest, nutze den Report-Only-Modus, um potenzielle Probleme zu identifizieren, ohne die Funktionalität deiner Seite zu beeinträchtigen:

add_header Content-Security-Policy-Report-Only "
    default-src 'self';
    report-uri /csp-report-endpoint;
" always;

So kannst du die CSP-Verstöße in deinen Logs analysieren und die Policy iterativ anpassen.

Weitere Best Practices für Web-Sicherheit

Abhängigkeiten regelmäßig prüfen (A06)

Vulnerable and Outdated Components lassen sich mit automatisierten Scans erkennen. Integriere diese Prüfungen in deine CI/CD-Pipeline:

# Node.js-Projekte
npm audit
npm audit fix

# Python-Projekte
pip-audit

# Docker-Images scannen
docker scout cves my-image:latest

# OWASP Dependency-Check (universell)
dependency-check --project "MyApp" --scan ./src

Sichere CI/CD-Pipeline mit SAST

Statische Code-Analyse erkennt Sicherheitslücken bereits während der Entwicklung. Ein Beispiel mit GitHub Actions:

name: Security Scan
on: [push, pull_request]

jobs:
  sast:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - name: Run Semgrep SAST
        uses: semgrep/semgrep-action@v1
        with:
          config: >-
            p/owasp-top-ten
            p/security-audit

      - name: Check dependencies
        run: npm audit --audit-level=high

Logging und Monitoring nicht vergessen (A09)

Viele Unternehmen bemerken Sicherheitsvorfälle erst nach Wochen oder Monaten. Richte ein zentrales Logging ein und überwache sicherheitsrelevante Ereignisse:

# Fehlgeschlagene Login-Versuche in Echtzeit überwachen
tail -f /var/log/auth.log | grep "Failed password"

# Fail2Ban installieren und konfigurieren
sudo apt install fail2ban
sudo systemctl enable fail2ban

Stelle sicher, dass du mindestens folgende Ereignisse loggst: fehlgeschlagene Logins, Zugriffsverletzungen, Eingabevalidierungsfehler und Änderungen an kritischen Konfigurationen.

HTTPS erzwingen

Ohne HTTPS sind alle anderen Maßnahmen wertlos, da Daten im Klartext übertragen werden. Mit Let's Encrypt gibt es keine Ausrede mehr:

# Certbot installieren und Zertifikat einrichten
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d example.com -d www.example.com

# Automatische Erneuerung testen
sudo certbot renew --dry-run

Checkliste: OWASP Top 10 absichern

Maßnahme	Schützt gegen
Prepared Statements / ORM	A03 – Injection
Security Headers setzen	A05 – Misconfiguration
CSP implementieren	A03 – XSS / Injection
Dependency Scanning	A06 – Vulnerable Components
MFA aktivieren	A07 – Auth Failures
HTTPS + HSTS	A02 – Cryptographic Failures
Zentrales Logging	A09 – Monitoring Failures
Input Validation	A03 – Injection

Fazit

Die OWASP Top 10 sind kein theoretisches Konstrukt – sie spiegeln die realen Bedrohungen wider, mit denen jede Webanwendung konfrontiert ist. Die gute Nachricht: Viele dieser Schwachstellen lassen sich mit verhältnismäßig einfachen Mitteln entschärfen. Security Headers und eine durchdachte Content Security Policy sind schnell implementiert und bieten sofortigen Schutz. Automatisierte Dependency-Scans in der CI/CD-Pipeline fangen verwundbare Bibliotheken ab, bevor sie in die Produktion gelangen.

Web-Sicherheit ist kein einmaliges Projekt, sondern ein fortlaufender Prozess. Beginne mit den hier vorgestellten Maßnahmen, teste deine Konfiguration regelmäßig mit Tools wie securityheaders.com oder dem OWASP ZAP Scanner und bleibe auf dem Laufenden, wenn die nächste Version der OWASP Top 10 veröffentlicht wird. Denn eines ist sicher: Die Angreifer entwickeln sich weiter – deine Verteidigung sollte das auch tun.