Kann HSTS-Preload sofort für die Produktionsdomäne aktiviert werden?

Nein. Testen Sie Strict-Transport-Security zunächst mit max-age=86400 (ein Tag) und stellen Sie sicher, dass alle Subdomains über HTTPS erreichbar sind, bevor Sie die Domain mit max-age=31536000 für hstspreload.org einreichen.

Wie implementiert man eine Content Security Policy ohne Skriptfehler?

Verwenden Sie zunächst den Header Content-Security-Policy-Report-Only, um Verstöße zu protokollieren, analysieren Sie externe Ressourcen und setzen Sie Nonces oder Hashes ein, bevor die Richtlinie aktiv blockiert.

Ratgeber

Fehlende Security-Header beheben (CSP, HSTS)

Fehlende HTTP-Sicherheitsheader setzen Webanwendungen Risiken wie Cross-Site Scripting (XSS), Clickjacking und Protokoll-Downgrades aus. Die Behebung erfordert präzise Header-Konfigurationen auf Webserver-Ebene.

Geprüft von WebAudit Lab · Aktualisiert 2026-10-02

Kurzantwort

Aktivieren Sie Strict-Transport-Security mit mindestens einem Jahr Laufzeit und Preload, konfigurieren Sie eine restriktive Content-Security-Policy, setzen Sie X-Content-Type-Options: nosniff und frame-ancestors 'none'.

Fehlende Sicherheitsheader diagnostizieren

Vor der Anpassung von Webserver-Konfigurationen sollten Sie die bestehenden HTTP-Antwort-Header mit curl -IL oder einem automatisierten Header-Scanner analysieren. Ermitteln Sie, auf welcher Ebene TLS terminiert und Header injiziert werden: Webserver (Nginx, Apache), Reverse-Proxy oder CDN. Stellen Sie sicher, dass Header nicht durch zwischengeschaltete Proxys entfernt werden.

Strict-Transport-Security (HSTS) sicher konfigurieren

HSTS zwingt Browser dazu, ausschließlich verschlüsselte HTTPS-Verbindungen aufzubauen, um Man-in-the-Middle-Angriffe zu verhindern. Beginnen Sie in einer Testumgebung mit max-age=86400 (ein Tag). Sobald alle Subdomains und Ressourcen nachweislich über HTTPS erreichbar sind, setzen Sie den Standardwert: max-age=31536000; includeSubDomains; preload. Setzen Sie in der Produktion niemals max-age=0 ein.

Eine robuste Content Security Policy (CSP) etablieren

CSP legt fest, aus welchen Quellen Skripte und Ressourcen im Browser geladen werden dürfen. Verwenden Sie zunächst den Header Content-Security-Policy-Report-Only mit report-to, um Richtlinienverletzungen ohne Blockierung zu protokollieren. Definieren Sie default-src 'self', script-src 'self' mit Nonces oder Hashes statt 'unsafe-inline', verbieten Sie Plugins über object-src 'none' und setzen Sie frame-ancestors 'none'.

Clickjacking, MIME-Sniffing und Referrer-Lecks verhindern

Schützen Sie Nutzersitzungen vor schadhafter Einbettung in unsichtbare Frames durch frame-ancestors 'none' in der CSP und ergänzendem X-Frame-Options: DENY. Verhindern Sie mit X-Content-Type-Options: nosniff, dass Browser Dateitypen eigenmächtig interpretieren. Begrenzen Sie die Weitergabe von URL-Parametern bei externen Links mit Referrer-Policy: strict-origin-when-cross-origin.

Serverkonfiguration und Verifikation

In Nginx werden die Header im HTTPS-Serverblock mit der add_header-Direktive und dem Parameter always definiert (z. B. add_header X-Content-Type-Options "nosniff" always;), damit sie auch bei 4xx- und 5xx-Fehlercodes ausgeliefert werden. In Apache nutzen Sie mod_headers mit Header always set. Überprüfen Sie die Syntax mit nginx -t und laden Sie den Dienst neu.

Security-Header: HTTPS, CSP, Frame-Schutz, MIME, Referrer und Browser-Isolation.

Kostenlosen Audit starten →