Härtung von HTTP-Sicherheitsheadern: Ein Schritt-für-Schritt-Implementierungsleitfaden

HTTP-Sicherheitsheader sind der kostengünstigste Sicherheitsmechanismus: Eine Handvoll Response-Header, einmalig auf dem Webserver oder CDN gesetzt, weist jeden Browser an, ganze Angriffsklassen abzuwehren – Clickjacking, Protokoll-Downgrades, MIME-Sniffing, Cross-Site-Datenlecks und große Teile von Cross-Site Scripting. Dennoch verzichten die meisten Websites darauf oder nutzen Werte aus Blogposts, die Funktionen fehlerhaft unterbrechen.

Dieser Leitfaden führt IT-Manager durch eine vollständige, gestufte Härtung der Header einer Produktions-Website: Bedeutung der Header, exakte Werte, Einführung der Content-Security-Policy ohne Website-Ausfälle, Server-Konfiguration für nginx und Apache sowie Verifizierung der Ergebnisse. Planen Sie einen Arbeitstag über zwei bis drei Wochen (die CSP-Report-Only-Phase beansprucht die meiste Zeit).

Wie Header Benutzer schützen

Jeder Header in diesem Leitfaden ist eine Anweisung Ihres Servers an den Browser. Der Browser setzt diese lokal durch – keine Appliance, kein Agent oder Code-Änderung nötig:

   Ihr Server                          Browser des Besuchers
   ----------                          ---------------------
   HTTP/1.1 200 OK
   Strict-Transport-Security  ------>   "Diese Seite nie wieder über HTTP laden"
   Content-Security-Policy    ------>   "Nur Skripte dieser Ursprünge ausführen"
   X-Frame-Options            ------>   "Darstellung in iframe verweigern"
   X-Content-Type-Options     ------>   "Dateitypen niemals raten"
   Referrer-Policy            ------>   "Keine vollständigen URLs an andere Sites senden"
   Permissions-Policy         ------>   "Kamera/Mikro/Standort nicht erlaubt"

Da die Durchsetzung im Browser erfolgt, schützen Header Ihre Benutzer, selbst wenn der Angriff Ihren Server nicht direkt betrifft – z. B. eine Phishing-Seite, die Ihr Anmeldeformular einbettet, oder ein injiziertes Werbeskript, das Formulardaten stiehlt.

Schritt 1 – Baseline: Messen, bevor Sie etwas ändern

Prüfen Sie Ihre Website mit einem Header-Scanner – der kostenlose security headers checker von FortifyNet bewertet jeden Header und zeigt Lösungen, securityheaders.com ist eine gute zweite Meinung. Speichern Sie das Ergebnis. Eine typische ungehärtete Website erhält ein F, da nur Server und X-Powered-By vorhanden sind – beides leckt Informationen, statt zu schützen.

Erfassen Sie zudem, was die Seite lädt. Prüfen Sie in den Browser-Entwicklertools (Reiter Network) auf den fünf wichtigsten Seiten jeden Drittanbieter-Ursprung: Analytik, Schriftarten, Tag-Manager, Chat-Widgets, Zahlungs-Iframes, Video-Embeds. Diese Liste wird in Schritt 4 Ihre CSP-Allowlist.

Schritt 2 – Fünf sichere Header sofort bereitstellen

Fünf Header sind für fast jede Website risikofrei und sollten im ersten Änderungsfenster implementiert werden.

Strict-Transport-Security (HSTS)

Erzwingt HTTPS für zukünftige Besuche, um SSL-Stripping-Angriffe in öffentlichem WLAN zu verhindern.

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

Beginnen Sie mit max-age=31536000 (ein Jahr) nur, wenn alle Subdomains bereits HTTPS nutzen; andernfalls starten Sie mit max-age=86400 und ohne includeSubDomains, dann erweitern. Nach Stabilisierung ist HSTS preload eine Option – fest in Browsern hinterlegt, eliminiert es das Zeitfenster beim ersten Besuch, ist aber faktisch unumkehrbar.

X-Content-Type-Options

X-Content-Type-Options: nosniff

Verhindert, dass Browser Dateitypen „erraten“, was verhindert, dass hochgeladene Dateien als Skripte ausgeführt werden. Es gibt keinen Grund, dies auszulassen.

X-Frame-Options

X-Frame-Options: DENY

Blockiert Clickjacking – Angreifer überlagern Ihre Seite mit unsichtbaren Schaltflächen. Nutzen Sie SAMEORIGIN, falls Ihre Seite sich selbst einbetten muss (Admin-Panels, Vorschau). Die moderne CSP frame-ancestors ersetzt diesen Header, behalten Sie aber beide für ältere Browser bei.

Referrer-Policy

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

Stellt sicher, dass Links auf externe Seiten nur Ihren Ursprung (https://example.com) zeigen statt der vollen URL – die Suchbegriffe, Pfade oder Token enthalten könnte. Dies ist Browser-Standard, aber die explizite Setzung garantiert den Schutz überall.

Permissions-Policy

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

Definiert, welche Browser-Features die Seite nutzen darf. Verbieten Sie alles Unnötige; ein kompromittiertes Drittanbieter-Skript kann dann nicht unbemerkt auf die Kamera zugreifen. Fügen Sie Features nur bei Bedarf hinzu (z.B. payment=(self "https://js.stripe.com")).

Schritt 3 – Header entfernen, die Informationen lecken

Entfernen Sie beim Bearbeiten der Konfiguration geschwätzige Defaults: Server-Versions-Strings und X-Powered-By. Sie bieten keinen Nutzen und liefern Angreifern exakte Softwareversionen für CVE-Abgleiche. In nginx: server_tokens off;. In Apache: ServerTokens Prod und ServerSignature Off. Für PHP: expose_php = Off.

Schritt 4 – Content-Security-Policy (CSP), der gestufte Ansatz

CSP ist der mächtigste Header – und der einzige, der Ihre Seite bei falscher Konfiguration zerstören kann. Kopieren Sie niemals eine CSP von anderen Sites. Folgen Sie diesem dreistufigen Prozess.

Stufe A: Report-Only (1–2 Wochen)

Implementieren Sie die Policy im Modus Content-Security-Policy-Report-Only. Browser evaluieren sie und melden Verstöße, blockieren aber nichts:

Content-Security-Policy-Report-Only: default-src 'self';
  script-src 'self' https://www.googletagmanager.com https://js.stripe.com;
  style-src 'self' 'unsafe-inline' https://fonts.googleapis.com;
  font-src 'self' https://fonts.gstatic.com;
  img-src 'self' data: https:;
  frame-src https://js.stripe.com https://www.youtube-nocookie.com;
  connect-src 'self' https://www.google-analytics.com;
  frame-ancestors 'none';
  report-uri /csp-report

Erstellen Sie die Allowlist basierend auf Ihrem Inventar aus Schritt 1. Leiten Sie report-uri an einen Endpunkt weiter und lassen Sie realen Traffic auf alle Seiten zugreifen, inklusive Checkout und selten genutzter Seiten, für mindestens eine Woche.

Stufe B: Verstöße beheben

Prüfen Sie die Reports und die Browser-Konsole. Häufige Befunde:

Der Goldstandard für Skripte sind Nonces: Der Server generiert pro Response einen Zufallswert, fügt ihn dem Header (script-src 'nonce-R4nd0m') und jedem erlaubten Skript-Tag hinzu. Injizierte Skripte ohne Nonce werden blockiert. 'strict-dynamic' (CSP Level 3) lässt ein Nonce-geprüftes Skript eigene Abhängigkeiten laden – dies ist Googles Empfehlung und verkleinert die Allowlist drastisch.

Akzeptieren Sie 'unsafe-inline' für Styles, falls die Entfernung unverhältnismäßig ist – das Risiko von inline CSS ist geringer als bei JS. Akzeptieren Sie niemals 'unsafe-inline' für Skripte; dies hebelt den Schutz aus.

Stufe C: Erzwingen

Benennen Sie den Header in Content-Security-Policy um, lassen Sie den Reporting-Endpunkt aktiv und beobachten Sie die ersten 48 Stunden. Bei Regressionen genügt eine Zeilenänderung für ein Rollback auf Report-Only.

Schritt 5 – Webserver-Konfiguration

Setzen Sie Header zentral – am Webserver oder CDN –, nicht in der Anwendung, damit jede Response (auch Fehlerseiten und statische Assets) abgedeckt ist.

nginx (innerhalb des server-Blocks; always ist nötig, damit Header auch bei 4xx/5xx-Responses angehängt werden):

server_tokens off;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "DENY" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header Content-Security-Policy "default-src 'self'; ..." always;

Achtung bei der nginx-Falle: add_header-Direktiven werden nicht vererbt, falls ein location-Block eigene add_header-Direktiven deklariert. Lassen Sie alle auf Server-Ebene oder wiederholen Sie den gesamten Satz.

Apache (in vhost oder .htaccess, mit mod_headers aktiv):

ServerTokens Prod
ServerSignature Off
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "DENY"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
Header always set Content-Security-Policy "default-src 'self'; ..."

Nutzen Sie bei CDNs (Cloudflare, CloudFront, Vercel, Netlify) die Response-Header-Transformationen, damit die Edge den Satz auch auf gecachte Responses anwendet.

Schritt 6 – Verifizieren und laufend prüfen

Nach jeder Änderung: Hard-Refresh mit geöffneten Dev-Tools, Response-Header lesen; erneut den headers checker ausführen und mit der Baseline aus Schritt 1 vergleichen. Eine gut gehärtete Seite erreicht Grad A.

Header unterliegen dem Verfall. Ein Redesign fügt ein Widget hinzu, das CSP blockiert; eine Migration auf einen neuen Load Balancer entfernt die Einstellungen. Automatisieren Sie die Prüfung – die kontinuierliche Überwachung von FortifyNet erkennt Header-Änderungen sofort, was manuelle Prozesse meist übersehen.

Cookie-Härtung – die vergessenen Response-Header

Session-Cookies werden ebenfalls per Response-Header gesetzt. Drei Attribute für jedes Set-Cookie:

Set-Cookie: session=abc123; Secure; HttpOnly; SameSite=Lax; Path=/

• Secure — Cookie wird nie über unverschlüsseltes HTTP gesendet. Mit HSTS schließt dies die Lücke.
• HttpOnly — JavaScript kann den Cookie nicht lesen; selbst erfolgreiches XSS kann das Session-Token nicht stehlen.
• SameSite=Lax (oder Strict) — Browser unterdrückt Cookies bei Cross-Site-Requests und neutralisiert CSRF-Angriffe ohne Code-Änderung. Nur bei zwingenden Cross-Site-Anforderungen (Widgets, SSO) SameSite=None; Secure nutzen.

Erwägen Sie Cookie-Präfixe: Ein Cookie namens __Host-session wird nur akzeptiert, wenn es Secure ist, kein Domain-Attribut hat und Path=/ — dies verhindert das Überschreiben durch kompromittierte Subdomains.

Cross-Origin-Isolation – COOP, CORP und CORS-Prüfung

Drei neuere Header steuern die Browser-Interaktion mit anderen Ursprüngen:

COOP: same-origin und CORP: same-origin sind sicher und sollten in Schritt 2 implementiert werden. COEP ist strikter – es unterbricht Cross-Origin-Bilder/Skripte ohne CORP-Header. Nutzen Sie es nur, wenn Sie Cross-Origin-Isolation benötigen und testen Sie vorab in Report-Only (Cross-Origin-Embedder-Policy-Report-Only existiert).

Prüfen Sie zudem CORS: Access-Control-Allow-Origin: * auf einer API mit Cookies ist eine Sicherheitslücke. Erlauben Sie nur spezifische Ursprünge und reflektieren Sie niemals ungeprüft den Origin-Header.

Caching sensibler Antworten

Sicherstellen, dass private Daten nicht dort gespeichert werden, wo Sie sie nicht löschen können. Für jede authentifizierte oder personenbezogene Antwort:

Cache-Control: no-store

no-store ist besser als Pragma/Expires und verhindert sowohl Browser- als auch Proxy-Caching. Der Klassiker: Ein Logout-Button funktioniert, aber der Zurück-Button zeigt die Seite aus dem Cache – no-store auf authentifizierten Seiten löst dies. Nutzen Sie langlebiges Caching (Cache-Control: public, max-age=31536000, immutable) nur für versionierte statische Assets.

Hinweise für SPAs und Frameworks

Single-Page-Applications ändern den CSP-Ansatz leicht:

• Die HTML-Shell wird einmal geladen, daher müssen Nonces pro Response an der Edge oder dem Server generiert werden – ein statischer Generator, der eine Nonce hartcodiert, bietet null Schutz. Falls die Seite komplett statisch ist, nutzen Sie Hashes (sha256-…) der spezifischen Inline-Skripte statt Nonces.
• Hydration-Frameworks (Next.js, Nuxt) nutzen Skript-Tags für State; beide unterstützen Nonce-Propagation via Middleware – nutzen Sie die dokumentierte CSP-Integration.
• connect-src ist für SPAs die aktivste Direktive: jeder API-Ursprung, Websocket-Endpunkt und Telemetrie-Sink muss gelistet sein. Fehlende Einträge führen zu stillem Versagen (Anfragen blockiert, Features tot) – ein weiterer Grund für den Report-Only-Pflichtschritt.
• Für APIs, die von Browsern konsumiert werden: Wenden Sie dieselben Header an (nosniff, no-store, restriktive CSP).

Verifizierung via Kommandozeile

Scanner sind bequem, aber Sie sollten Header auch direkt prüfen – besonders bei Debugging, warum Header auf manchen Routen fehlen (nginx-Vererbung, CDN-Transformationen, Framework-Überschreibungen). Nutzen Sie curl mit dem Head-Request-Flag (-I) oder das Netzwerk-Panel der Dev-Tools und lesen Sie die Roh-Header für: Homepage, authentifizierten Bereich und eine nicht existierende Seite. Eine saubere Antwort:

HTTP/2 200
content-security-policy: default-src 'self'; ...
permissions-policy: camera=(), microphone=(), geolocation=()
referrer-policy: strict-origin-when-cross-origin
strict-transport-security: max-age=31536000; includeSubDomains
x-content-type-options: nosniff
x-frame-options: DENY

Prüfen Sie alle drei Fälle: Homepage, authentifizierte Route, 404. Wiederholen Sie dies über HTTP und HTTPS, sowie auf www- und Bare-Domain-Varianten – Redirects stammen oft aus Konfigurationsblöcken ohne Härtung, und SSL-Stripping beginnt genau dort. Die Fehlerseite ist die andere klassische Lücke.

Zwei weitere automatisierbare Gewohnheiten:

• CI-Check: Ein Skript in der Deployment-Pipeline, das die Staging-URL per curl prüft und den Build bei fehlenden Headern stoppt. Dies verhindert Regressionen durch neue Load Balancer.
• Change-Alerting: Externe Überwachung, die Header nach Zeitplan prüft und bei Änderungen alarmiert – Teil der FortifyNet-Überwachung, um Regressionen zu erkennen, die CI verpasst (z. B. manuelle CDN-Änderungen).

Häufige Mythen und Fehler

• "Wir haben eine WAF, Header sind redundant." Eine WAF prüft eingehenden Traffic; Header steuern, was der Browser mit Ihren Seiten tut, auch bei Angriffen, die Ihre Infrastruktur nie berühren. Sie sind komplementäre Schichten.
• "X-XSS-Protection sollte aktiviert sein." Nein – dieser Header ist veraltet; Auditoren, die das Fehlen bemängeln, sind veraltet. Moderne Browser haben den XSS-Auditor entfernt. Setzen Sie ihn auf 0 oder löschen Sie ihn komplett; CSP ist der Ersatz.
• "CSP hat die Seite einmal zerstört, also haben wir es gelöscht." Das Problem war der Verzicht auf Report-Only, nicht CSP selbst. Wiederholen Sie den gestuften Prozess.
• "Grad A bedeutet sicher." Header sind nur eine Schicht. Eine A-Seite mit ungepatchtem CMS ist noch immer nur ein Plugin-CVE von einer Kompromittierung entfernt – deshalb ist der Header-Scan nur ein Test unter vielen in einem FortifyNet-Audit.

Rollout-Checkliste

• Baseline-Scan gespeichert; Drittanbieter-Inventar vollständig
• HSTS, nosniff, X-Frame-Options, Referrer-Policy, Permissions-Policy bereitgestellt
• Server/X-Powered-By-Versions-Lecks entfernt
• CSP im Report-Only-Modus mit Reporting-Endpunkt
• Verstöße triagiert; Nonces für Skripte genutzt; kein 'unsafe-inline' für script-src
• CSP erzwungen; frame-ancestors gesetzt; Reporting aktiv
• Header zentral (Server/CDN), always/Header always genutzt
• Re-Scan zeigt Grad A; kontinuierliche Überwachung aktiv

Quellen

• MDN — Referenz der HTTP-Response-Header
• OWASP Secure Headers Project
• W3C — Content Security Policy Level 3
• Google web.dev — XSS-Mitigation mit strikter CSP
• RFC 6797 — HTTP Strict Transport Security
• hstspreload.org — HSTS Preload-Einreichung