HTTP Security Header — Best Practices + Konfiguration

Falsch oder gar nicht gesetzte HTTP-Header sind die häufigste Lücke moderner Web-Konfigurationen — und gleichzeitig die einfachste zu schließen. Diese Anleitung zeigt die sechs wichtigsten Security-Header, wie sie wirken, mit fertigen nginx- und Apache-Beispielen sowie einer Audit-Checklist am Ende.

Schnellantwort

Setzen Sie diese Header auf jedem öffentlichen Webserver:

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload
Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), camera=(), microphone=()

Prüfen Sie das Ergebnis mit unserem HTTP Header Check — die Note sollte mindestens B sein. Für A sind feinere CSP-Direktiven nötig.

Die sechs wichtigsten Header im Detail

1. Strict-Transport-Security (HSTS)

Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Sagt dem Browser: für die nächsten 365 Tage immer HTTPS, nie HTTP. Verhindert SSL-Stripping-Angriffe in offenen WLANs.

• max-age in Sekunden, Empfehlung: 31536000 (1 Jahr).
• includeSubDomains — gilt auch für mail.example.com, api.example.com etc.
• preload — Voraussetzung für die Chrome HSTS Preload List. Browser laden Ihre Site dann von Anfang an HTTPS-only, bevor der erste Request rausgeht.

Mehr Hintergrund: HSTS im Glossar.

2. Content-Security-Policy (CSP)

Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self'

Der mächtigste Security-Header — und der trickreichste. Definiert, von welchen Domains der Browser Scripts, Styles, Bilder, Fonts & Co. laden darf. Schutz gegen XSS und Code-Injection.

Direktiven verstehen:

Empfehlung für die Praxis: beginnen Sie mit Content-Security-Policy-Report-Only (gleiches Format, aber nur Reporting, kein Blocken). Sehen Sie zwei Wochen lang in den Reports, was geblockt würde — dann schalten Sie auf scharf.

3. X-Frame-Options

X-Frame-Options: SAMEORIGIN

Verhindert Clickjacking: Ihre Seite kann nicht in einem <iframe> einer fremden Domain geladen werden. Werte:

• DENY — gar kein Framing erlaubt.
• SAMEORIGIN — nur dieselbe Origin darf framen (Standard für die meisten Sites).
• ALLOW-FROM uri — eine bestimmte Origin (deprecated, durch CSP frame-ancestors ersetzt).

CSP frame-ancestors ist die moderne Variante und überschreibt X-Frame-Options in neuen Browsern — aber X-Frame-Options als Backup zu setzen schadet nicht.

4. X-Content-Type-Options

X-Content-Type-Options: nosniff

Verhindert MIME-Sniffing: der Browser akzeptiert nur den vom Server gemeldeten Content-Type und „erratet" keinen alternativen. Schutz gegen Tricks wie als Bild getarnte JS-Dateien, die der Browser ausführt, sobald er den JS-Code im „Bild" erkennt.

Nur ein gültiger Wert: nosniff. Sollte auf jedem Server gesetzt sein, immer.

5. Referrer-Policy

Referrer-Policy: strict-origin-when-cross-origin

Steuert, welche Referrer-Info bei Klicks auf externe Links gesendet wird. Datenschutz-relevant — der Standard-Browser-Wert verrät bei jedem Outbound-Link die vollständige URL inkl. Query-Parameter an die Ziel-Site.

Empfohlene Werte:

6. Permissions-Policy

Permissions-Policy: geolocation=(), camera=(), microphone=(), payment=()

Der Nachfolger von Feature-Policy. Schaltet Browser-APIs (Kamera, Mikrofon, Geolocation, Payment Request & Co.) für Ihre Site explizit ab, wenn sie nicht benötigt werden. Reduziert Angriffsoberfläche: selbst wenn ein XSS-Angriff durchkommt, kann der eingespielte Code z. B. nicht auf die Kamera zugreifen.

Leeres () heißt: ganz aus. (self) heißt: nur eigene Domain. (self "https://trusted.com") heißt: eigene + eine externe.

Beispielkonfiguration: nginx

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

    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
    add_header Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:" always;
    add_header X-Content-Type-Options "nosniff" always;
    add_header X-Frame-Options "SAMEORIGIN" always;
    add_header Referrer-Policy "strict-origin-when-cross-origin" always;
    add_header Permissions-Policy "geolocation=(), camera=(), microphone=()" always;

    # ... rest of your config
}

Das always-Flag ist wichtig — ohne werden die Header bei 4xx/5xx-Responses nicht gesendet.

Beispielkonfiguration: Apache

In .htaccess oder Vhost-Config (mod_headers muss aktiv sein):

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
    Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:"
    Header always set X-Content-Type-Options "nosniff"
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set Permissions-Policy "geolocation=(), camera=(), microphone=()"
</IfModule>

Audit-Checklist

Vor und nach jedem Deploy:

1. ☐ HSTS gesetzt mit max-age ≥ 1 Jahr
2. ☐ CSP gesetzt (nicht nur Report-Only)
3. ☐ X-Content-Type-Options: nosniff
4. ☐ X-Frame-Options ODER CSP frame-ancestors
5. ☐ Referrer-Policy mindestens strict-origin-when-cross-origin
6. ☐ Permissions-Policy für nicht benötigte APIs leer gesetzt
7. ☐ Kein Server-Header mit Versionsnummer (Information Disclosure)
8. ☐ Kein X-Powered-By: PHP/8.x (gleicher Grund)
9. ☐ Mit HTTP Header Check gegen die Live-URL prüfen
10. ☐ Im Idealfall: Score A erreicht

Häufige Fallstricke

Inline-Scripts in CSP zulassen? 'unsafe-inline' öffnet XSS-Tür. Bessere Lösung: nonces oder hashes nutzen — Beispiel script-src 'self' 'nonce-r4nd0m'. Jeder zulässige <script>-Tag bekommt das gleiche Nonce-Attribut, generiert pro Request.

X-XSS-Protection: 0 oder weglassen? Der alte Header ist deprecated. Moderne Browser ignorieren ihn. Wenn Sie ihn setzen, dann X-XSS-Protection: 0 — alles andere kann tatsächlich neue Schwachstellen öffnen.

HSTS auf einer Subdomain einbauen, die ich nicht überall verwendet habe? Vorsicht mit includeSubDomains — wenn legacy.example.com noch HTTP läuft, sperren Sie sich selbst aus. Erst aufräumen, dann HSTS aktivieren.

Preload-Liste — geht das wieder weg? Theoretisch ja (Removal-Antrag), praktisch dauert es Wochen bis Monate, bis alle Browser-Versionen den Entry verlernen. Nicht ohne Plan eintragen.

Häufige Fragen

Verschlechtert CSP die Performance? Nicht relevant. Die Header sind wenige hundert Bytes pro Response. Was kostet ist die Pflege — bei komplexen Sites mit vielen Drittanbieter-Skripten muss man CSP regelmäßig anpassen.

Reicht es, Header nur auf HTTPS zu setzen? HSTS kann nur über HTTPS wirken. Der Rest ist auch über HTTP nutzbar, aber wenn jemand HTTP nutzt, ist das eh kein sicheres Setup. Generell: ganz auf HTTP verzichten und Port 80 nur auf 301-Redirect zu HTTPS umlenken.

Was wenn Cloudflare oder ein anderer CDN davor sitzt? Cloudflare kann viele Header automatisch hinzufügen — prüfen Sie ihre „Security Headers"-Page-Rule. Bei DIY-CDN-Setup (z. B. eigener nginx als Reverse Proxy): Header im Reverse-Proxy setzen, nicht im Backend, da der Browser sie vom Edge-Server sieht.

Wie oft muss ich neu prüfen? Mindestens nach jedem größeren Deploy. Idealerweise täglich automatisiert — z. B. UptimeRobot Heartbeat-Monitoring kombiniert mit einem Cron, der gegen den HTTP Header Check läuft und bei Score-Abfall alarmiert.

Verwandte Tools auf einen Blick

• HTTP Header Check — Live-Audit Ihrer Header
• SSL Check — TLS-Konfiguration und Zertifikatskette
• Artikel Ports und Firewalls — die Netzwerk-Ebene unter den Headern
• Glossar HSTS und TLS