Security Headers und CSP
HTTP-Security-Header sind eine schnelle und effektive Schutzmaßnahme: Der Server teilt dem Browser mit, welches Verhalten erlaubt oder verboten ist. Das kostet keine Rechenzeit, erfordert keine Code-Änderungen an der Anwendungslogik und schützt trotzdem gegen ganze Angriffsklassen. Viele der wichtigsten Webangriffe – XSS, Clickjacking, Protocol-Downgrade, MIME-Sniffing – können durch korrekt konfigurierte Security-Header erheblich erschwert oder verhindert werden.
Besonders mächtig ist die Content Security Policy (CSP) – ein granularer Header, der exakt definiert, von welchen Quellen der Browser Skripte, Stylesheets, Bilder und andere Ressourcen laden darf. Ein korrekt konfiguriertes CSP macht Inline-<script>-Tags wirkungslos – selbst wenn ein Angreifer XSS-Code einschleust, kann der Browser ihn nicht ausführen.
1) Security-Header im Überblick
Die folgenden Header sind in der Praxis am relevantesten. Grün markierte sind Pflicht für jede öffentliche Webanwendung, blaue sind empfohlen. Klicke auf einen Header für Erklärung, Beispielwert und Angriffsvektor den er schützt.
http:// eingibt.Schützt gegen: SSL-Stripping-Angriffe (Angreifer degradiert HTTPS auf HTTP im MITM-Szenario). Protocol-Downgrade-Angriffe.
Empfohlener Wert:
Strict-Transport-Security: max-age=31536000; includeSubDomains; preloadmax-age=31536000 = 1 Jahr. includeSubDomains: auch für alle Subdomains. preload: Browser-interne Liste für bekannte HSTS-Seiten.
Schützt gegen: XSS – selbst wenn Schadcode eingeschleust wird, darf der Browser ihn nicht ausführen. Data-Exfiltration durch unerlaubte Verbindungen.
Beispiel:
Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'Details und Builder: Abschnitt 2 unten.
<iframe> eingebettet wird.Schützt gegen: Clickjacking – Angreifer blendet die Zielseite transparent über eine harmlose Seite. Opfer klickt auf scheinbar harmlosen Button, tatsächlich auf verdeckten „Bestätigen"-Button der Zielseite.
Werte:
DENY (nie einbetten), SAMEORIGIN (nur gleiche Domain). Wurde weitgehend durch CSP frame-ancestors ersetzt, aber X-Frame-Options hat breitere Browserunterstützung.
Schützt gegen: MIME-Sniffing-Angriffe: Angreifer lädt eine Datei mit schädlichem JavaScript als
image/png hoch – ohne diesen Header würde der Browser es trotzdem als Skript ausführen.Wert:
X-Content-Type-Options: nosniff – einziger gültiger Wert.
Referer-Header beim Navigieren auf externe Seiten mitgeschickt werden.Schützt gegen: Informationslecks – interne URLs (mit Token, Nutzer-IDs) erscheinen nicht im Referer-Header externer Dienste.
Empfohlen:
Referrer-Policy: strict-origin-when-cross-origin – sendet nur den Ursprung bei Cross-Site-Navigationen, ohne Pfad und Parameter.
Schützt gegen: Unbefugte Nutzung von Browser-APIs durch eingebetteten Code (XSS, schädliche iFrames).
Beispiel:
Permissions-Policy: camera=(), microphone=(), geolocation=() – deaktiviert alle drei Features komplett.
2) CSP-Builder
Content Security Policy kann komplex werden. Der folgende Builder hilft dir, eine sinnvolle CSP für eine typische Webanwendung zusammenzustellen. Aktiviere die Direktiven, die du benötigst, und wähle die erlaubten Quellen.
nonce), fügt ihn in den CSP-Header ein und als Attribut in das <script>-Tag. Nur Skripte mit dem richtigen Nonce werden ausgeführt. Ein Angreifer kann den Nonce nicht vorhersagen.Zusammenfassung
Security-Header sind einfach zu implementieren und decken wichtige Angriffsvektoren ab. Pflicht: HSTS (HTTPS-Erzwingung), CSP (XSS-Schutz), X-Frame-Options (Clickjacking), X-Content-Type-Options (MIME-Sniffing). CSP ist das mächtigste Werkzeug – eine strenge CSP macht XSS selbst bei vorhandener Lücke oft harmlos. Verwandte Themen: XSS verhindern, CSRF-Schutz, TLS/HTTPS Handshake.