Security Header: Schutzschicht für moderne Websites

HTTP-Security-Header sind spezielle Anweisungen, die ein Webserver an den Browser des Besuchers sendet. Sie aktivieren integrierte Sicherheitsmechanismen moderner Browser und schützen Ihre Website effektiv vor Cross-Site Scripting (XSS), Clickjacking, Man-in-the-Middle-Angriffen und unerwünschtem MIME-Sniffing.

Die wichtigsten Security Header im Überblick

Ein modernes Sicherheitskonzept erfordert die korrekte Konfiguration mehrerer Header.

1. Content Security Policy (CSP)

Die CSP schränkt die Quellen für ausführbaren Code drastisch ein. Ein Angreifer, der bösartigen HTML-Code in ein Gästebuch einschleust, scheitert, da der Browser den externen Schadcode nicht lädt.

• Beispiel: Content-Security-Policy: default-src 'self'; script-src 'self' https://trustedscripts.com;

2. HTTP Strict Transport Security (HSTS)

HSTS verhindert, dass Verbindungen versehentlich unverschlüsselt über HTTP aufgebaut werden. Es blockiert Versuche von Man-in-the-Middle-Angreifern, HTTPS-Verbindungen auf unverschlüsseltes HTTP herunterzustufen (SSL Stripping).

• Beispiel: Strict-Transport-Security: max-age=63072000; includeSubDomains; preload

3. X-Frame-Options

Schützt Ihre Website vor Clickjacking. Damit wird verhindert, dass Ihre Seite in einem unsichtbaren <iframe> einer fremden Angreifer-Website eingebettet wird, um Klicks der Benutzer abzufangen.

• Beispiel: X-Frame-Options: DENY (Einbetten generell verbieten) oder SAMEORIGIN (Einbetten nur durch eigene Domain erlauben).

4. X-Content-Type-Options

Unterbindet das sogenannte MIME-Sniffing. Wenn ein Angreifer ein manipuliertes Skript als Bild hochlädt, könnte ein Browser versuchen, die Datei fälschlicherweise als JavaScript auszuführen. Dieser Header zwingt den Browser dazu, den vom Server deklarierten Inhaltstyp strikt zu befolgen.

• Beispiel: X-Content-Type-Options: nosniff

5. Referrer-Policy

Regelt, wie viele Informationen über die Herkunfts-URL (Referrer) beim Klicken auf ausgehende Links an die Zielseite übermittelt werden. Wichtig für die Privatsphäre der Nutzer.

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

---

Security-Header nach Schutzwirkung

Nicht jeder Header wehrt dieselbe Angriffsklasse ab. Die folgende Tabelle ordnet die wichtigsten Header ihrem Risiko zu und nennt einen sinnvollen Startwert:

Header	Schützt vor	Empfohlener Startwert	Bruchrisiko
CSP	XSS, Code-Injection	Report-Only, dann restriktiv	hoch
HSTS	SSL-Stripping, MITM	max-age=31536000; includeSubDomains	mittel
X-Frame-Options	Clickjacking	DENY oder SAMEORIGIN	gering
X-Content-Type-Options	MIME-Sniffing	nosniff	gering
Referrer-Policy	Daten-Leak über Referer	strict-origin-when-cross-origin	gering

Die wirtschaftlichste Reihenfolge: zuerst die risikoarmen Header mit geringem Bruchrisiko, dann HSTS mit kurzer Laufzeit, zuletzt die CSP im Report-Only-Modus. So schliessen Sie ganze Angriffsklassen, ohne legitime Funktionen zu zerstören. Für fortgeschrittene Isolation ergänzen COOP, COEP und CORP den Schutz vor Side-Channel-Angriffen.

Das Prinzip dahinter ist Defense in Depth: Mehrere unabhängige Schutzschichten greifen, sodass ein einzelner Konfigurationsfehler nicht sofort die ganze Anwendung kompromittiert. Das folgende Diagramm zeigt, welche Schicht welche Angriffsklasse abfängt:

graph LR
    Angriff[Eingehende Anfrage / Angriff] --> TLS[TLS + HSTS: erzwingt HTTPS]
    TLS --> CSP[CSP: blockiert fremde Skripte / XSS]
    CSP --> XFO[X-Frame-Options: verhindert Clickjacking]
    XFO --> XCTO[X-Content-Type-Options: stoppt MIME-Sniffing]
    XCTO --> App[Geschützte Anwendung]

---

CSP Best Practices & Umsetzung

Die Erstellung einer fehlerfreien CSP ist komplex, da moderne Websites oft viele Skripte (Analysen, Schriften, Tracker) nutzen.

1. Vermeiden Sie unsafe-inline: Das Erlauben von Inline-Skripten (<script>alert(1)</script>) hebelt den XSS-Schutz der CSP nahezu vollständig aus.
2. Nutzen Sie Hashes oder Nonces: Wenn Inline-Skripte unumgänglich sind, signieren Sie diese im Build-Prozess mit einer kryptografischen Prüfsumme (Hash) oder einer einmaligen Zufallszahl (Nonce). Astro integriert diese Hashes beispielsweise direkt im Build.
3. Starten Sie im Report-Only-Modus: Verwenden Sie zunächst den Header Content-Security-Policy-Report-Only. Der Browser blockiert keine Ressourcen, sendet aber Berichte über Verstösse an eine definierte URL, sodass Sie Ihre Richtlinie gefahrlos optimieren können.

---

Nginx-Konfigurationsbeispiel

Um diese Sicherheits-Header global auszuliefern, können Sie Nginx wie folgt konfigurieren:

  # Security Header in Nginx ausliefern (siehe einzelne Leitfaeden auf Allerate)
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains; preload" always; # siehe /security-header/hsts/
add_header X-Frame-Options "DENY" always; # siehe /security-header/x-frame-options/
add_header X-Content-Type-Options "nosniff" always; # siehe /security-header/x-content-type-options/
add_header Referrer-Policy "strict-origin-when-cross-origin" always; # siehe /security-header/referrer-policy/
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always; # siehe /security-header/permissions-policy/

---

Alle Security-Header-Leitfäden im Überblick

Hier finden Sie unsere detaillierten Fachartikel zu den einzelnen Sicherheits-Headern:

• Zentrale Header: HSTS | X-Frame-Options | X-Content-Type-Options
• Richtlinien & Berechtigungen: Content Security Policy (CSP) | Referrer-Policy | Permissions-Policy
• Spezialthemen & Praxis: CSP Best Practices | COOP, COEP & CORP (Side-Channel) | Security Header Checkliste

[!TIP] Sind Ihre Sicherheits-Header optimal konfiguriert und Ihre CSP fehlerfrei? Prüfen Sie die Sicherheit Ihrer Seite live mit dem Security Header Check und dem CSP Evaluator auf balou.tools.