HTTP-Sicherheitsheader: CSP, HSTS, Permissions-Policy und vollständige Konfiguration

Sie sind keine Firewall und sie reparieren weder defekte Autorisierung, verwundbare APIs, SQL-Injection, geleakte Zugangsdaten noch veraltete Abhängigkeiten. Security-Header sind eine Defense-in-Depth-Schicht: Sie reduzieren die Angriffsfläche des Browsers und schränken ein, was passieren kann, nachdem eine andere Schwachstelle bereits ausgenutzt wurde.

Im Jahr 2026 ist es sinnvoll, drei Kategorien zu unterscheiden:

1. Baseline-Header, die für die meisten Websites sinnvoll sind.
2. Architekturabhängige Header, die OAuth, Zahlungen, CDNs, iframes oder die PDF-Auslieferung stören können, wenn sie ohne Analyse kopiert werden.
3. Veraltete Header, die nicht einfach aktiviert werden sollten, um die Bewertung eines veralteten Scanners zu verbessern.

TL;DR: Beginnen Sie mit einer sorgfältig entworfenen Content Security Policy, HSTS nachdem HTTPS vollständig ausgerollt ist, X-Content-Type-Options: nosniff, einer expliziten Referrer-Policy und einer zurückhaltenden Permissions-Policy. Verwenden Sie CSP frame-ancestors als primäre Kontrolle gegen Framing und behalten Sie X-Frame-Options nur als Kompatibilitätsschicht bei. Setzen Sie COOP, COEP und CORP erst nach Prüfung der Cross-Origin-Integrationen ein. Entfernen oder deaktivieren Sie X-XSS-Protection, Expect-CT, HPKP und den alten Header Report-To.

Empfehlungen und Kompatibilität wurden zuletzt am 23. Juli 2026 überprüft.

Die wichtigsten Header im Überblick

Header	Typische Empfehlung	Was es einschränkt	Überall verwenden?
Content-Security-Policy	anwendungsspezifische Policy, vorzugsweise nonce- oder hash-basiert	XSS, Injection, nicht genehmigte Ressourcen-Origins und Framing	ja für HTML, nach dem Testen
Strict-Transport-Security	max-age=31536000; includeSubDomains; preload nur nach Prüfung hinzufügen	HTTP-Downgrade und Umgehen von Zertifikatsfehlern	ja, wenn die gesamte Domain HTTPS-fähig ist
X-Content-Type-Options	nosniff	MIME-Sniffing und einige MIME-Verwechslungen	ja
Referrer-Policy	strict-origin-when-cross-origin oder strenger	Leaks von URL-Pfad und Query	ja
Permissions-Policy	ungenutzte Funktionen deaktivieren, etwa camera=(), microphone=(), geolocation=()	Nutzung ausgewählter Browser-APIs durch Dokumente und Frames	meist, nach dem Testen der Funktionen
CSP frame-ancestors	'none', 'self' oder explizite Origins	Clickjacking und unerwünschtes Framing	ja für HTML-Dokumente
X-Frame-Options	DENY oder SAMEORIGIN aus Kompatibilitätsgründen	Framing in älteren Implementierungen	oft, zusätzlich zu frame-ancestors
Cross-Origin-Opener-Policy	oft same-origin, sofern keine Popup-Beziehungen benötigt werden	einige XS-Leaks und Zugriff über window.opener	architekturabhängig
Cross-Origin-Embedder-Policy	require-corp oder credentialless, nur bewusst	Einbetten von Cross-Origin-Ressourcen ohne Erlaubnis	nein, nicht automatisch
Cross-Origin-Resource-Policy	same-origin, same-site oder cross-origin je Ressource	unerwünschte No-CORS-Cross-Origin-Lesezugriffe	ressourcenabhängig
Cache-Control	no-store für hochsensible Antworten; private für personalisierte Inhalte	Speicherung in Browser- und Zwischen-Caches	für sensible Antworten
Set-Cookie	Secure; HttpOnly; SameSite=Lax/Strict je nach Bedarf	Diebstahl und unangebrachtes Cross-Site-Senden von Cookies	für Session-Cookies
Reporting-Endpoints	Endpunkt für CSP-/COOP-/COEP-Berichte	Beobachtbarkeit der Policies	optional
X-XSS-Protection	weglassen oder auf 0 setzen	veralteter XSS-Filter	nicht aktivieren
Expect-CT	entfernen	veralteter Certificate-Transparency-Mechanismus	nein
Public-Key-Pins	nicht verwenden	historisches Certificate Pinning	nein

OWASP betrachtet Response-Header als wertvolle Härtungsmaßnahmen, betont aber, dass jeder Wert zum Antworttyp und zur Anwendungsarchitektur passen muss.

Ein minimaler Ausgangspunkt

Dies ist eine Ausgangsvorlage, keine universelle Copy-and-paste-Lösung:

Content-Security-Policy: default-src 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none'; form-action 'self'; img-src 'self' data: https:; font-src 'self'; style-src 'self'; script-src 'self'; connect-src 'self'; upgrade-insecure-requests
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
X-Frame-Options: DENY

Diese Policy blockiert Inline-Skripte und -Styles, nicht aufgeführte Ressourcen-Origins, Framing, an andere Origins gesendete Formulare, den Zugriff auf Kamera/Mikrofon/Geolocation sowie die HTTP-Navigation, nachdem HSTS gespeichert wurde.

Wenn die Website externe Schriftarten, Analytics, Karten, Zahlungs-Widgets, OAuth, Tag-Manager, Drittanbieter-APIs oder Inline-Code verwendet, muss die Policy angepasst werden.

1. Content-Security-Policy: der mächtigste und schwierigste Header

Content-Security-Policy legt fest, von wo der Browser Skripte, Styles, Bilder, Schriftarten, Frames und Netzwerkverbindungen laden darf. Eine korrekte CSP kann die Auswirkungen von XSS und Data-Injection erheblich verringern, ersetzt aber nicht die Eingabevalidierung, die Ausgabecodierung und sichere DOM-APIs.

Zentrale Direktiven

Direktive	Zweck	Üblicher Startwert
default-src	Fallback für Ressourcentypen ohne eigene Direktive	'self'
script-src	erlaubte Skripte	Nonce oder Hashes, optional 'self'
style-src	erlaubte Styles	'self', Nonce oder Hashes
img-src	Bilder	'self' data: https:
font-src	Schriftarten	'self' und explizite CDN-Origins
connect-src	Fetch, XHR, WebSocket und EventSource	Ihre API und explizite Endpunkte
frame-src	von der Seite eingebettete Frames	nur erforderliche Origins
frame-ancestors	welche Eltern-Dokumente diese Seite einbetten dürfen	'none' oder 'self'
form-action	gültige Formularziele	'self' oder explizite Endpunkte
base-uri	erlaubte <base>-URLs	'self' oder 'none'
object-src	<object>- und <embed>-Plugins	'none'
upgrade-insecure-requests	HTTP-Subressourcen auf HTTPS umschreiben	kein Wert

Allowlists versus strikte CSP

Eine Domain-Allowlist kann fragil werden. Ein vertrauenswürdiges CDN kann viele nicht zusammenhängende Dateien hosten, und ein Drittanbieter-Loader kann dynamisch weitere Abhängigkeiten nachladen. web.dev empfiehlt eine strikte CSP auf Basis von Nonces oder Hashes; strict-dynamic erlaubt es, dass von einem vertrauenswürdigen Skript geladene Skripte dieses Vertrauen erben.

Beispiel für eine Nonce-Policy:

Content-Security-Policy:
  default-src 'self';
  base-uri 'self';
  object-src 'none';
  frame-ancestors 'none';
  form-action 'self';
  script-src 'nonce-{RANDOM_NONCE}' 'strict-dynamic';
  style-src 'self' 'nonce-{RANDOM_NONCE}';
  img-src 'self' data: https:;
  font-src 'self';
  connect-src 'self' https://api.example.com;
  upgrade-insecure-requests

Passendes HTML:

<script nonce="{RANDOM_NONCE}">
  window.__APP_CONFIG__ = { apiUrl: "https://api.example.com" };
</script>

Ein Nonce muss unvorhersehbar sein, für jede HTML-Antwort eindeutig, im Header und in den vertrauenswürdigen Elementen vorhanden und vom Server generiert. Ein konstanter, in der Konfiguration gespeicherter Nonce bietet nicht den beabsichtigten Schutz. Für statische Seiten, die pro Anfrage keinen neuen Wert erzeugen können, können Hashes praktischer sein.

unsafe-inline und unsafe-eval vermeiden

'unsafe-inline' in script-src erlaubt Inline-JavaScript und schwächt den XSS-Schutz erheblich. 'unsafe-eval' aktiviert APIs, die Zeichenketten als Code ausführen, darunter eval() und der Function-Konstruktor.

Fügen Sie sie nicht hinzu, nur um Konsolenmeldungen zu unterdrücken. Stattdessen:

1. verschieben Sie Inline-Code in externe Dateien;
2. verwenden Sie einen Nonce oder Hash;
3. identifizieren Sie die Abhängigkeit, die eval benötigt;
4. suchen Sie nach einer anderen Build- oder Bibliothekskonfiguration.

Trusted Types

Eine Policy wie:

Content-Security-Policy: require-trusted-types-for 'script'; trusted-types app-policy

kann typisierte Werte an ausgewählten DOM-XSS-Sinks wie innerHTML verlangen. Seit Februar 2026 ist require-trusted-types-for in aktuellen großen Browsern verfügbar, ältere Versionen unterstützen es jedoch möglicherweise nicht.

Trusted Types ist eine fortgeschrittene Schutzmaßnahme. Die Anwendung muss sichere Transformations-Policies definieren, und Frameworks sowie Abhängigkeiten müssen kompatibel sein. Das bloße Hinzufügen des Headers reicht nicht aus.

Mit Report-Only beginnen

Ein sichererer Rollout beginnt mit:

Content-Security-Policy-Report-Only: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; report-to csp-endpoint
Reporting-Endpoints: csp-endpoint="https://example.com/security/csp-reports"

Content-Security-Policy-Report-Only meldet Verstöße, ohne Ressourcen zu blockieren, sodass fehlende Origins und unterbrochene Abläufe vor der Durchsetzung erkannt werden können. Reporting-Endpoints ersetzt den veralteten Header Report-To und sollte für aktuelle Deployments bevorzugt werden.

Ein Reporting-Endpunkt sollte Grenzen für die Payload-Größe, Rate-Limiting, sicheres Logging, Ausgabecodierung und eine kurze, zweckgebundene Aufbewahrungsfrist durchsetzen. CSP-Berichte können URLs und Ressourcendetails enthalten.

2. Strict-Transport-Security: HTTPS ohne Downgrade-Pfad

HSTS teilt dem Browser mit, dass ein Host nur über HTTPS kontaktiert werden darf. Nach dem Speichern hebt der Browser künftige HTTP-Versuche an und verhindert, dass Nutzer einige Zertifikatsfehler umgehen.

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

• max-age=31536000 speichert die Policy für ein Jahr.
• includeSubDomains erfasst Subdomains.
• preload signalisiert die Absicht, in die Preload-Liste der Browser aufgenommen zu werden.

Nicht mit preload beginnen

Ein fehlerhaftes HSTS-Deployment kann legitime Nutzer aussperren. Eine alte, nur über HTTP erreichbare Subdomain, ein abgelaufenes Zertifikat oder ein Drittanbieter-Dienst unter Ihrer Domain können includeSubDomains und ein langes max-age gefährlich machen.

Ein vorsichtiger Rollout kann Folgendes verwenden:

5 minutes → 1 day → 1 week → 1 month → 1 year

Testen Sie in jeder Phase die Apex-Domain, aktive Subdomains, Wildcard- und SAN-Zertifikate, Legacy-Dienste, Admin-Panels, APIs und Partner-Endpunkte.

HSTS-Preload erfordert ein gültiges Zertifikat, HTTP-zu-HTTPS-Weiterleitungen, ein ausreichend langes max-age, includeSubDomains und das preload-Token. Die Entfernung kann Wochen dauern, da die Liste in den Browsern ausgeliefert wird.

3. X-Content-Type-Options: MIME-Raten verhindern

X-Content-Type-Options: nosniff

Dies weist den Browser an, den deklarierten Content-Type zu respektieren, statt eine Antwort als anderen Typ neu zu interpretieren. Skripte und Styles können blockiert werden, wenn ihr MIME-Typ nicht dem Erwarteten entspricht.

Es ersetzt keine korrekte Serverkonfiguration. Antworten benötigen weiterhin korrekte Werte:

Content-Type: text/html; charset=utf-8
Content-Type: text/css; charset=utf-8
Content-Type: application/javascript; charset=utf-8
Content-Type: application/json; charset=utf-8
Content-Type: image/avif

Dies ist besonders wichtig für Nutzer-Uploads, Download-Endpunkte, dynamisch generierte Dateien, Object Storage, CDNs und Fehlerantworten, die möglicherweise HTML statt JSON zurückgeben.

4. Referrer-Policy: URL-Leaks reduzieren

Referrer-Policy steuert, wie viel der aktuellen Seiten-URL im Referer-Header gesendet werden darf, wenn eine andere Ressource angefordert wird.

Eine sinnvolle Voreinstellung ist:

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

Sie sendet die vollständige URL bei Same-Origin-Anfragen, nur den Origin bei Cross-Origin-HTTPS-Anfragen und keinen Referrer bei einem Downgrade von HTTPS auf HTTP.

Strengere Alternativen sind:

Referrer-Policy: no-referrer

oder:

Referrer-Policy: same-origin

Die Wahl kann sich auf Analytics, Affiliate-Systeme und Zahlungsanbieter auswirken. Geheimnisse, Tokens, E-Mail-Adressen und personenbezogene Daten sollten ohnehin nicht in URLs abgelegt werden.

5. Clickjacking-Schutz: frame-ancestors und X-Frame-Options

Die flexibelste Kontrolle ist CSP:

Content-Security-Policy: frame-ancestors 'none'

oder:

Content-Security-Policy: frame-ancestors 'self' https://portal.partner.example

frame-ancestors legt fest, welche Eltern-Dokumente ein Dokument in <frame>, <iframe>, <object> oder <embed> einbetten dürfen.

Fügen Sie aus Kompatibilitätsgründen Folgendes hinzu:

X-Frame-Options: DENY

oder:

X-Frame-Options: SAMEORIGIN

MDN empfiehlt frame-ancestors für moderne Deployments, weil es ausdrucksstärker ist. ALLOW-FROM ist veraltet und kann dazu führen, dass aktuelle Browser den Header ignorieren. X-Frame-Options muss ein HTTP-Header sein; eine <meta http-equiv>-Variante hat keine Wirkung.

6. Permissions-Policy: nicht genutzte Funktionen deaktivieren

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

Der Header steuert den Zugriff eines Dokuments und seiner Frames auf ausgewählte Browser-Funktionen, darunter Kamera, Mikrofon und Geolocation.

Den aktuellen Origin erlauben:

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

Oder einen expliziten Origin erlauben:

Permissions-Policy: geolocation=(self "https://maps.example")

Kopieren Sie nicht eine riesige Liste jeder bekannten Direktive. Einzelne Direktiven haben unterschiedliche Browser-Unterstützung und manche bleiben experimentell. Ermitteln Sie die von der Anwendung genutzten Funktionen und deaktivieren Sie dann relevante ungenutzte Funktionen explizit.

7. COOP, COEP und CORP: Cross-Origin-Isolation ist keine universelle Voreinstellung

Diese Header sind verwandt, lösen aber unterschiedliche Probleme.

Cross-Origin-Opener-Policy

Cross-Origin-Opener-Policy: same-origin

COOP steuert, ob über Navigation oder window.open() geöffnete Dokumente eine Browsing-Context-Group teilen. same-origin trennt das Dokument von Cross-Origin-Openern und mindert einige XS-Leaks.

Es kann OAuth-Popups, Zahlungsfenster und Integrationen, die auf window.opener angewiesen sind, stören. In manchen Fällen ist Folgendes passender:

Cross-Origin-Opener-Policy: same-origin-allow-popups

Cross-Origin-Embedder-Policy

Cross-Origin-Embedder-Policy: require-corp

COEP verlangt, dass Cross-Origin-no-cors-Ressourcen die Erlaubnis über CORP erteilen oder mit CORS abgerufen werden. Fehlende Header können Bilder, Schriftarten, Skripte, Frames und andere Drittanbieter-Assets blockieren.

Eine Alternative ist:

Cross-Origin-Embedder-Policy: credentialless

Dies erlaubt einige no-cors-Ressourcen ohne explizites CORP, entfernt dabei aber Credentials wie Cookies.

Cross-Origin-Resource-Policy

Cross-Origin-Resource-Policy: same-origin

CORP ist eine Policy für die Ressource selbst und kann Folgendes verwenden:

• same-origin,
• same-site,
• cross-origin.

Es ist kein Ersatz für CORS. MDN dokumentiert außerdem ein Chrome-Problem mit teilweisem PDF-Rendering unter einigen CORP-Deployments, daher sollte der Header nicht ohne Tests global angewendet werden.

Das Paar:

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

ermöglicht die Cross-Origin-Isolation, die von ausgewählten fortgeschrittenen APIs benötigt wird, einschließlich des vollständigen SharedArrayBuffer-Zugriffs. Setzen Sie es nicht allein wegen einer Scanner-Bewertung ein.

8. Sichere Cookies und Caching

Set-Cookie und Cache-Control werden nicht immer als Security-Header aufgeführt, schützen aber direkt Sessions und sensible Daten.

Session-Cookie

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

• Secure beschränkt die Übertragung auf HTTPS.
• HttpOnly verhindert den Zugriff durch JavaScript.
• SameSite begrenzt das Cross-Site-Senden.
• __Host- erfordert Secure, Path=/ und kein Domain und bindet das Cookie enger an den Host.

SameSite=Strict ist stärker, kann aber die Rückkehr von Login- oder Zahlungsanbietern stören. SameSite=None erfordert Secure und sollte nur für ein tatsächlich Cross-Site-Cookie verwendet werden.

Sensible Antworten

Cache-Control: no-store

Dies fordert private und gemeinsam genutzte Caches auf, die Antwort nicht zu speichern. Personalisierte Inhalte, die im Browser, aber nicht von Zwischeninstanzen zwischengespeichert werden dürfen, können Folgendes verwenden:

Cache-Control: private, no-cache

MDN empfiehlt, personalisierte Antworten explizit als private zu kennzeichnen, um versehentliches gemeinsames Caching zu vermeiden.

9. Offenlegung der Technologie reduzieren

Header wie:

Server: nginx/1.24.0
X-Powered-By: PHP/8.4
X-AspNet-Version: 4.0.30319

erleichtern das Fingerprinting. Ihr Entfernen verbirgt den Stack nicht vor einem entschlossenen Angreifer, vermeidet aber die direkte Offenlegung der Version.

• entfernen Sie X-Powered-By;
• deaktivieren Sie Framework-Versionsheader;
• begrenzen Sie die Details in Server;
• veröffentlichen Sie keine absichtlich falsche Version;
• verwechseln Sie Verschleierung nicht mit Patchen.

OWASP empfiehlt, X-Powered-By zu entfernen und Server zu begrenzen, weist aber darauf hin, dass Technologien weiterhin auf andere Weise abgeleitet werden können.

10. Veraltete Header und irreführende Ratschläge

X-XSS-Protection

Nicht aktivieren:

X-XSS-Protection: 1; mode=block

OWASP warnt, dass veraltete XSS-Filter in ansonsten sicheren Seiten Schwachstellen erzeugen können. Lassen Sie den Header weg oder deaktivieren Sie ihn explizit:

X-XSS-Protection: 0

Verwenden Sie stattdessen CSP, Ausgabecodierung und sichere APIs.

Expect-CT

Expect-CT ist in der Praxis veraltet, da aktuelle Clients Certificate Transparency für moderne Zertifikate voraussetzen. MDN beschreibt es seit Juni 2021 als weitgehend veraltet.

Public-Key-Pins

HPKP sollte nicht eingesetzt werden. Ein falscher Pin könnte Nutzer für lange Zeit aussperren, und der Header wurde aus modernen Browsern entfernt. Bevorzugen Sie korrektes TLS, automatische Erneuerung, CAA, Zertifikatsüberwachung und sorgfältig geprüftes HSTS-Preload.

Report-To

Das alte:

Report-To: { ... }

ist veraltet. Verwenden Sie:

Reporting-Endpoints: csp="https://example.com/reports/csp"

Access-Control-Allow-Origin: *

CORS ist kein Bündel von Härtungsheadern, das global hinzugefügt wird. Access-Control-Allow-Origin lockert die Same-Origin-Policy. Credential-behaftete API-Antworten können den Wildcard * nicht sicher mit authentifiziertem Cross-Origin-Zugriff kombinieren. Erlauben Sie nur erforderliche Origins und validieren Sie sie serverseitig.

11. Beispiele für Serverkonfigurationen

Nginx

add_header Content-Security-Policy "default-src 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none'; form-action 'self'; img-src 'self' data: https:; style-src 'self'; script-src 'self'; connect-src 'self'; upgrade-insecure-requests" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header X-Frame-Options "DENY" always;

always ist wichtig, weil es die Header auch bei Fehler- und Nicht-Standard-Statusantworten beibehält.

Apache

<IfModule mod_headers.c>
  Header always set Content-Security-Policy "default-src 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none'; form-action 'self'; img-src 'self' data: https:; style-src 'self'; script-src 'self'; connect-src 'self'; upgrade-insecure-requests"
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  Header always set X-Content-Type-Options "nosniff"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
  Header always set X-Frame-Options "DENY"
</IfModule>

PHP

<?php

header("Content-Security-Policy: default-src 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none'; form-action 'self'; img-src 'self' data: https:; style-src 'self'; script-src 'self'; connect-src 'self'; upgrade-insecure-requests");
header("Strict-Transport-Security: max-age=31536000; includeSubDomains");
header("X-Content-Type-Options: nosniff");
header("Referrer-Policy: strict-origin-when-cross-origin");
header("Permissions-Policy: camera=(), microphone=(), geolocation=()");
header("X-Frame-Options: DENY");

Header müssen vor dem Response-Body gesendet werden. Erzeugen Sie für jede Anfrage separat einen kryptografisch zufälligen Nonce.

Node.js / Express

app.use((req, res, next) => {
  res.setHeader(
    "Content-Security-Policy",
    "default-src 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none'; form-action 'self'; img-src 'self' data: https:; style-src 'self'; script-src 'self'; connect-src 'self'; upgrade-insecure-requests"
  );
  res.setHeader(
    "Strict-Transport-Security",
    "max-age=31536000; includeSubDomains"
  );
  res.setHeader("X-Content-Type-Options", "nosniff");
  res.setHeader("Referrer-Policy", "strict-origin-when-cross-origin");
  res.setHeader(
    "Permissions-Policy",
    "camera=(), microphone=(), geolocation=()"
  );
  res.setHeader("X-Frame-Options", "DENY");
  res.removeHeader("X-Powered-By");
  next();
});

Eine Website, die CDNs, WebSockets, OAuth, Zahlungen oder Karten nutzt, benötigt eine umfassendere, aber weiterhin explizite CSP.

12. Ein Rollout-Prozess, der Ausfälle vermeidet

Inventarisierung

Listen Sie alle Skript-, Style-, Schrift- und Bild-Origins auf; API- und WebSocket-Endpunkte; iframes; OAuth-/Zahlungs-Popups; CDN-Ressourcen; Nutzer-Uploads; HSTS-Subdomains und die von der Anwendung genutzten Browser-Funktionen.

Beobachten

• führen Sie CSP im Report-Only-Modus aus;
• sammeln Sie Berichte und Verstöße aus der Browser-Konsole;
• testen Sie jeden kritischen Nutzerpfad;
• beziehen Sie mobile und unterstützte Browser ein;
• prüfen Sie Fehlerseiten, Weiterleitungen und statische Assets.

Schrittweise durchsetzen

• beginnen Sie mit object-src, base-uri, frame-ancestors und form-action;
• gehen Sie zu statischen Ressourcen über;
• setzen Sie ein striktes script-src zuletzt durch;
• erhöhen Sie das HSTS-max-age schrittweise;
• testen Sie COOP/COEP separat gegen Popup- und Cross-Origin-Integrationen.

Regressionen überwachen

CI-Tests sollten repräsentative URLs abrufen, doppelte oder widersprüchliche Header erkennen, MIME-Typen bestätigen, versehentliches Entfernen von CSP/HSTS erkennen und End-to-End-Login- und Zahlungsabläufe ausführen.

13. So testen Sie Header

Prüfen Sie die Antwort direkt:

curl -I https://example.com/

Folgen Sie Weiterleitungen:

curl -IL https://example.com/

Untersuchen Sie eine bestimmte Ressource:

curl -I https://example.com/assets/app.js

Überprüfen Sie die Header auf der Startseite, beim Login sowie bei 404- und 500-Antworten; bestätigen Sie, dass CSP nicht mit widersprüchlichen Policies dupliziert wird; stellen Sie sicher, dass HSTS nur über HTTPS gesendet wird; prüfen Sie die MIME-Typen; und vergewissern Sie sich, dass ein CDN oder Reverse-Proxy die Header nicht entfernt hat.

Der kostenlose POLPROG Security Headers Inspector prüft HSTS, CSP, Framing-Schutz und weitere Kontrollen. Nutzen Sie den DNS & SSL Inspector für Zertifikats- und DNS-Prüfungen und den Website Health Check für eine umfassendere Überprüfung von SEO, Performance, Barrierefreiheit und Sicherheit.

Deployment-Checkliste

CSP

• Restriktives default-src.
• object-src 'none'.
• Eingeschränktes base-uri.
• frame-ancestors entspricht dem tatsächlichen Einbettungsmodell.
• form-action beschränkt die Formularziele.
• Inline-Code verwendet bei Bedarf einen Nonce oder Hash.
• Der Nonce ist pro Antwort eindeutig.
• Kein ungerechtfertigtes 'unsafe-inline'.
• Kein ungerechtfertigtes 'unsafe-eval'.
• Policy zuerst im Report-Only-Modus getestet.
• Der Report-Endpunkt hat Rate-Limits und begrenzte Aufbewahrung.

HTTPS und HSTS

• Jede Seite und Ressource funktioniert über HTTPS.
• HTTP leitet direkt auf HTTPS weiter.
• Zertifikate werden überwacht.
• Alle Subdomains sind inventarisiert.
• max-age in Stufen erhöht.
• includeSubDomains ist sicher.
• preload erst nach Prüfung der Konsequenzen hinzugefügt.

Weitere Kontrollen

• X-Content-Type-Options: nosniff.
• Korrekter Content-Type bei jeder Antwort.
• Explizite Referrer-Policy.
• Permissions-Policy deaktiviert ungenutzte Funktionen.
• Kein ALLOW-FROM in X-Frame-Options.
• COOP stört OAuth oder Zahlungen nicht.
• COEP blockiert keine erforderlichen Drittanbieter-Assets.
• CORP entspricht dem Sharing-Modell jeder Ressource.
• Session-Cookies verwenden Secure, HttpOnly und ein passendes SameSite.
• Sensible Antworten verwenden korrektes Cache-Control.
• Technologie-Versionsheader sind entfernt.
• X-XSS-Protection ist nicht vorhanden oder deaktiviert.
• Expect-CT, HPKP und altes Report-To sind entfernt.

Fazit

Für die meisten Unternehmenswebsites und Webanwendungen lautet die richtige Reihenfolge:

1. Korrektes HTTPS, korrekte MIME-Typen und sichere Cookies.
2. Eine anwendungsspezifische CSP, ausgerollt über Report-Only.
3. HSTS in Stufen ausgerollt.
4. nosniff, Referrer-Policy, Permissions-Policy und Framing-Schutz.
5. COOP, COEP und CORP nur, wenn das Cross-Origin-Modell verstanden ist.
6. Entfernung veralteter und Informationen preisgebender Header.

Der beste Satz an Security-Headern ist nicht der längste. Es ist die kleinste Policy, die genau zur Anwendung passt, das Testen der kritischen Pfade übersteht und nach jedem Deployment weiterhin überwacht wird.