Security Header Checkliste: Server sicher konfigurieren

Die korrekte Konfiguration von HTTP-Security-Headern ist eine der schnellsten und effektivsten Härtungsmassnahmen für Webserver. Sie schützt Websites ohne nennenswerten Performance-Verlust vor XSS, Clickjacking, SSL-Stripping und Datenabflüssen. Nutzen Sie diese Checkliste, um die Sicherheitskonfiguration Ihrer Webserver (Nginx, Apache, IIS) systematisch zu überprüfen und zu optimieren.

Die einzelnen Header sind jeweils in eigenen Beiträgen vertieft – von der Content-Security-Policy über HSTS bis zu X-Frame-Options. Diese Seite bündelt sie zu einer prüfbaren Reihenfolge.

Die 5 unverzichtbaren Core-Security-Header

Diese Header bilden das Fundament und sollten auf jedem produktiv genutzten Webserver aktiv sein:

Header	Schützt vor	Empfohlener Wert	Einführungsrisiko
Content-Security-Policy	XSS, Data Injection	default-src 'self'; object-src 'none'	hoch (zuerst Report-Only)
Strict-Transport-Security	SSL-Stripping	max-age=31536000; includeSubDomains	mittel (HTTPS prüfen)
X-Frame-Options	Clickjacking	DENY	gering
X-Content-Type-Options	MIME-Sniffing	nosniff	sehr gering
Referrer-Policy	Datenabfluss über Referer	strict-origin-when-cross-origin	sehr gering

1. Content-Security-Policy (CSP)

• Zweck: Schutz vor Cross-Site Scripting (XSS) und Data Injection.
• Empfehlung (Mindest-Standard): default-src 'self'; object-src 'none'; base-uri 'self';
• Prüfung: Wurde auf 'unsafe-inline' verzichtet? Sind Nonces/Hashes für legitime Inline-Skripte aktiv?

2. Strict-Transport-Security (HSTS)

• Zweck: Erzwingt verschlüsselte HTTPS-Verbindungen und verhindert SSL-Stripping.
• Empfehlung: max-age=31536000; includeSubDomains; preload
• Prüfung: Sind alle Subdomains per SSL abgesichert, bevor includeSubDomains gesetzt wird?

3. X-Frame-Options (XFO)

• Zweck: Schutz vor Clickjacking-Angriffen.
• Empfehlung: DENY (oder SAMEORIGIN, falls die Seite intern geframed werden muss).
• Prüfung: Wird parallel die modernere CSP-Direktive frame-ancestors verwendet?

4. X-Content-Type-Options (XCTO)

• Zweck: Verhindert MIME-Sniffing und das Ausführen getarnter Skripte.
• Empfehlung: nosniff
• Prüfung: Ist dieser Header auf allen statischen und dynamischen Routen aktiv?

5. Referrer-Policy

• Zweck: Verhindert das Abfliessen sensibler URL-Pfade und Parameter bei Klicks auf externe Links.
• Empfehlung: strict-origin-when-cross-origin
• Prüfung: Werden Query-Parameter bei externen Links sauber abgeschnitten?

---

Zusätzliche Header für erweiterten Schutz

• Permissions-Policy: Deaktiviert ungenutzte Browser-APIs zur Verkleinerung der Angriffsfläche.
  • Empfehlung: camera=(), microphone=(), geolocation=(), payment=()
• Cross-Origin-Opener-Policy (COOP) & Cross-Origin-Embedder-Policy (COEP): Isolieren die Seite im Browser-Prozess (Schutz vor CPU-Side-Channel-Angriffen).
  • Empfehlung (nur bei Bedarf für SharedArrayBuffer): Cross-Origin-Opener-Policy: same-origin, Cross-Origin-Embedder-Policy: require-corp

---

Nginx-Konfigurationsvorlage (Best Practice)

Hinterlegen Sie die Header im server-Block Ihrer Nginx-Konfiguration. Verwenden Sie den Zusatz always, damit die Header auch bei Fehlerseiten (z. B. 404 oder 500) ausgeliefert werden:

  # Security Header Best Practice Configuration
add_header Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'self';" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
add_header X-Frame-Options "DENY" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), camera=(), microphone=(), payment=()" always;

---

Häufige Fehler bei der Implementierung

• Doppelte Deklaration: Wenn ein Header sowohl in der Nginx-Konfiguration als auch im Backend (z. B. durch eine Spring-Boot-Sicherheitskonfiguration) gesetzt wird, senden Server den Header doppelt. Viele Browser verwerfen den Header daraufhin komplett, da er ungültig wird.
• Fehlendes „always“ in Nginx: Wird das Wort always weggelassen, fehlen die Header auf Fehlerseiten, was Angreifern gerade dort (z. B. auf manipulierten 404-Seiten) Angriffsflächen bietet.
• CSP zu früh scharf geschaltet: Eine direkt aktive, strikte CSP blockiert oft legitime Inline-Skripte oder Third-Party-Ressourcen und zerstört die Darstellung. Testen Sie sie zuerst über Content-Security-Policy-Report-Only.
• HSTS ohne HTTPS-Abdeckung: Wird includeSubDomains gesetzt, bevor alle Subdomains ein gültiges HSTS-fähiges Zertifikat besitzen, werden diese im Browser unerreichbar.

---

Vorher/Nachher: Eine Website systematisch härten

Eine bestehende Webanwendung wird ohne Codeänderung, allein über die Serverkonfiguration, abgesichert:

• Vorher: Keine Security-Header gesetzt. Ein Online-Scanner vergibt die Note F. Die Seite ist anfällig für Clickjacking (sie lässt sich in einen Frame laden) und MIME-Sniffing.
• Nachher: Die fünf Core-Header werden über die Nginx-Vorlage gesetzt, die CSP zunächst im Report-Only-Modus getestet und nach zwei Wochen ohne Verstösse scharf geschaltet. Der Scanner vergibt die Note A.
• Wirkung: Die Angriffsfläche sinkt drastisch, ohne dass eine einzige Zeile Anwendungscode geändert wurde – eine der höchsten Sicherheits-Renditen im gesamten Security-Header-Bereich.

---

Schnell-Checkliste zum Abhaken

• HSTS aktiv mit max-age ≥ 1 Jahr und geprüfter Subdomain-Abdeckung
• CSP ohne 'unsafe-inline', zuerst per Report-Only getestet
• X-Frame-Options DENY oder CSP frame-ancestors 'none'
• X-Content-Type-Options nosniff auf allen Routen
• Referrer-Policy strict-origin-when-cross-origin
• Permissions-Policy deaktiviert ungenutzte Browser-APIs
• Alle Header auch auf Fehlerseiten (Nginx always)
• Keine doppelten Header aus Server und Backend

[!TIP] Die Härtung Ihrer Webserver-Konfiguration ist die schnellste Methode, um die Sicherheit Ihres gesamten Systems signifikant zu steigern. Prüfen Sie die Security-Header Ihrer Live-Website mit dem Security Header Check auf balou.tools.