Website Security Header prüfen: CSP, HSTS und Co. erklärt

Ein gültiges SSL-Zertifikat ist heute selbstverständlich. Doch HTTPS ist nur ein Teil einer sicheren Website-Konfiguration.

Moderne Browser unterstützen zahlreiche sogenannte HTTP Security Header. Damit kann ein Webserver dem Browser beispielsweise mitteilen:

• von welchen Quellen JavaScript geladen werden darf
• ob eine Website in einem fremden iFrame angezeigt werden darf
• ob Verbindungen ausschließlich über HTTPS erfolgen sollen
• welche Browserfunktionen eine Seite verwenden darf
• welche Referrer-Informationen beim Aufruf anderer Websites übertragen werden

Richtig konfigurierte Security Header können damit eine zusätzliche Verteidigungsschicht gegen verschiedene Angriffsarten schaffen. OWASP empfiehlt den Einsatz geeigneter HTTP Response Header ausdrücklich als Bestandteil einer sicheren Webanwendung – siehe dazu das OWASP HTTP Headers Cheat Sheet. Sie ersetzen weder sichere Programmierung noch Updates, Firewall, TLS oder ein funktionierendes Patchmanagement. Sie ergänzen diese Maßnahmen jedoch um Schutzmechanismen direkt im Browser. Nach demselben Least-Privilege-Prinzip solltest du auch andere privilegierte Schnittstellen deiner Infrastruktur absichern – zum Beispiel einen MCP Server, mit dem KI-Agenten Zugriff auf reale Systeme erhalten. MCP Server sicher betreiben: Rechte, Tools und Risiken erklärt (Zum Artikel)

Das Gute daran: Du kannst die Security Header praktisch jeder öffentlich erreichbaren Website innerhalb weniger Sekunden überprüfen. Nach einem ganz ähnlichen Prinzip lässt sich übrigens auch die E-Mail-Sicherheit einer Domain überprüfen. SPF, DKIM und DMARC einfach erklärt – E-Mail-Sicherheit prüfen (Zum Artikel)

Was sind HTTP Security Header?

Bei jedem Aufruf einer Website kommunizieren Browser und Webserver über HTTP beziehungsweise HTTPS.

Der Server liefert dabei nicht nur HTML, Bilder oder JavaScript aus. Vor dem eigentlichen Inhalt werden verschiedene HTTP Response Header übertragen.

Ein vereinfachtes Beispiel:

HTTP/2 200
content-type: text/html
strict-transport-security: max-age=31536000
x-content-type-options: nosniff
referrer-policy: strict-origin-when-cross-origin
content-security-policy: default-src 'self'

Einige dieser Header enthalten Informationen über die ausgelieferte Ressource. Andere definieren Regeln, die der Browser beim Umgang mit der Website berücksichtigen soll.

Genau hier kommen die Security Header ins Spiel.

Welche Website Security Header sind wichtig?

Für normale Websites und Webanwendungen solltest du insbesondere folgende Header kennen:

Security Header	Aufgabe
Content-Security-Policy	Beschränkt erlaubte Ressourcen und Skripte
Strict-Transport-Security	Erzwingt HTTPS
X-Content-Type-Options	Verhindert MIME-Type-Sniffing
X-Frame-Options	Schutz vor Clickjacking
Referrer-Policy	Steuert übertragene Referrer-Daten
Permissions-Policy	Beschränkt Browserfunktionen
Cross-Origin-Opener-Policy	Isoliert Browser-Kontexte

Nicht jede Website benötigt exakt dieselbe Konfiguration. Besonders Content Security Policy und Cross-Origin-Regeln müssen zur jeweiligen Anwendung passen.

1. Content Security Policy – CSP erklärt

Die Content Security Policy, kurz CSP, gehört zu den leistungsfähigsten Security Headern.

Der Header lautet:

Content-Security-Policy

Mit einer CSP legt der Betreiber fest, welche Ressourcen der Browser laden oder ausführen darf.

Mozilla beschreibt CSP als Mechanismus, mit dem sich unter anderem Risiken durch Cross-Site-Scripting und andere eingeschleuste Inhalte reduzieren lassen.

Eine sehr einfache Policy könnte beispielsweise so aussehen:

Content-Security-Policy: default-src 'self';

'self' bedeutet vereinfacht:

Ressourcen dürfen standardmäßig nur von derselben Herkunft geladen werden.

Eine umfangreichere Policy könnte beispielsweise so aussehen:

Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; upgrade-insecure-requests;

Damit werden unterschiedliche Bereiche separat eingeschränkt.

Typische CSP-Direktiven

• default-src
• script-src
• style-src
• img-src
• font-src
• connect-src
• frame-src
• frame-ancestors
• object-src
• base-uri
• form-action

Besonders wichtig ist beispielsweise:

frame-ancestors 'none'

Damit kann verhindert werden, dass die Seite von anderen Websites in Frames oder iFrames eingebettet wird. Die frame-ancestors-Direktive ist speziell für die Kontrolle solcher Einbettungen vorgesehen.

Vorsicht: CSP nicht einfach kopieren

Bei kaum einem anderen Security Header kann eine unüberlegte Konfiguration so schnell Funktionen einer Website beschädigen.

Websites laden häufig Inhalte von:

• Google Analytics
• Google Fonts
• Content Delivery Networks
• Zahlungsanbietern
• Karten-Diensten
• YouTube
• Werbenetzwerken
• externen APIs
• Consent-Managern
• JavaScript-Bibliotheken

Wer einfach

default-src 'self'

aktiviert, kann dadurch große Teile seiner Website blockieren.

CSP deshalb zuerst testen

Eine Policy kann zunächst mit folgendem Header getestet werden:

Content-Security-Policy-Report-Only

Im Report-Only-Modus kann eine CSP untersucht werden, ohne dass die Richtlinie bereits vollständig durchgesetzt wird. Mozilla empfiehlt diesen Mechanismus ausdrücklich für das Testen und Analysieren möglicher CSP-Verstöße.

Für produktive Systeme gilt deshalb:

CSP entwickeln → testen → Verstöße analysieren → schrittweise verschärfen → erst danach erzwingen.

Das gilt besonders, wenn du dir eine CSP von ChatGPT vorschlagen lässt: Eine generierte Policy solltest du niemals ungeprüft in die Produktion übernehmen. Wann du KI-Outputs im Admin-Alltag grundsätzlich kritisch hinterfragen musst, erklärt Wann du KI-Outputs im Admin-Alltag hinterfragen musst (Zum Artikel).

2. Strict-Transport-Security – HSTS erklärt

Der zweite besonders wichtige Header ist:

Strict-Transport-Security

Kurz: HSTS – HTTP Strict Transport Security.

HSTS teilt einem Browser mit, dass eine Website ausschließlich über HTTPS aufgerufen werden soll.

Ein Beispiel:

Strict-Transport-Security: max-age=31536000

max-age wird in Sekunden angegeben.

31536000 Sekunden entsprechen ungefähr einem Jahr.

Mit:

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

wird die Regel zusätzlich auf Subdomains angewendet.

Browser merken sich die HSTS-Information und versuchen zukünftige Verbindungen direkt über HTTPS aufzubauen. Außerdem werden Zertifikatsprobleme bei bekannten HSTS-Hosts strenger behandelt.

Was bedeutet HSTS Preload?

Man findet häufig folgende Konfiguration:

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

Damit kann eine Domain grundsätzlich für eine HSTS-Preload-Liste vorbereitet werden.

Das bedeutet vereinfacht: Unterstützte Browser können bereits wissen, dass diese Domain ausschließlich über HTTPS erreichbar sein soll, bevor sie die Website erstmals besucht haben.

Das klingt hervorragend – ist aber eine Entscheidung mit Konsequenzen.

includeSubDomains und preload nicht leichtfertig aktivieren

Bevor du diese Optionen verwendest, solltest du sicherstellen, dass wirklich:

• die Hauptdomain HTTPS unterstützt
• alle relevanten Subdomains HTTPS unterstützen
• Zertifikate zuverlässig erneuert werden
• keine alten Anwendungen ausschließlich über HTTP erreichbar sind

Google warnt ebenfalls davor, HSTS zu aktivieren, bevor der HTTPS-Betrieb dauerhaft zuverlässig funktioniert, und empfiehlt bei der Einführung zunächst niedrigere max-age-Werte.

Ein falsch eingesetztes HSTS kann dazu führen, dass Benutzer bestimmte Systeme überhaupt nicht mehr erreichen können.

3. X-Content-Type-Options

Dieser Header ist wesentlich einfacher:

X-Content-Type-Options: nosniff

Er verhindert sogenanntes MIME-Type-Sniffing.

Browser sollen also den vom Server angegebenen Content-Type respektieren und nicht versuchen, selbst einen anderen Dateityp zu erraten. Mozilla nennt nosniff ausdrücklich als Schutz vor MIME-Type-Sniffing.

Für viele Websites gehört dieser Header deshalb zur sinnvollen Basiskonfiguration.

4. X-Frame-Options

Der Header:

X-Frame-Options

soll kontrollieren, ob eine Website innerhalb eines Frames dargestellt werden darf.

Häufige Einstellungen sind:

X-Frame-Options: DENY

oder:

X-Frame-Options: SAMEORIGIN

DENY: Die Seite darf grundsätzlich nicht in einem Frame dargestellt werden.

SAMEORIGIN: Die Seite darf nur innerhalb eines Frames derselben Origin verwendet werden.

Damit lässt sich insbesondere das Risiko sogenannter Clickjacking-Angriffe reduzieren.

Mozilla dokumentiert X-Frame-Options weiterhin als Schutzmechanismus zur Kontrolle der Darstellung in Frames.

Bei modernen Anwendungen sollte gleichzeitig die CSP-Direktive frame-ancestors betrachtet werden. Sie erlaubt deutlich präzisere Regeln.

5. Referrer-Policy

Beim Anklicken eines Links kann der Browser Informationen darüber übertragen, von welcher Seite ein Benutzer kommt.

Welche Informationen dabei weitergegeben werden, lässt sich über folgenden Header beeinflussen:

Referrer-Policy

Eine häufig sinnvolle Einstellung lautet:

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

Damit lässt sich kontrollieren, wie viele Informationen bei gleichen oder unterschiedlichen Origins übertragen werden.

Mozilla beschreibt Referrer-Policy genau als Mechanismus zur Steuerung der im Referer-Header übertragenen Informationen.

6. Permissions-Policy

Moderne Browser besitzen zahlreiche leistungsfähige APIs.

Beispielsweise für: Kamera, Mikrofon, Standort, Vollbildmodus, Sensoren, Payment-Funktionen.

Über:

Permissions-Policy

kann eine Website festlegen, welche Funktionen verwendet werden dürfen.

Beispiel:

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

Damit werden Kamera, Mikrofon und Standort für das Dokument deaktiviert.

Mozilla beschreibt Permissions-Policy als Mechanismus, mit dem Browserfunktionen sowohl für das eigene Dokument als auch für eingebettete Frames zugelassen oder verweigert werden können.

Auch hier gilt: Nicht blind alles deaktivieren.

Eine Website mit Kartenfunktion benötigt möglicherweise Geolocation. Eine Videokonferenz-Anwendung benötigt Kamera und Mikrofon. Die Policy muss daher zur Anwendung passen.

7. Cross-Origin-Opener-Policy und weitere moderne Header

Bei komplexeren Webanwendungen begegnet man außerdem Headern wie:

Cross-Origin-Opener-Policy
Cross-Origin-Embedder-Policy
Cross-Origin-Resource-Policy

Beispielsweise:

Cross-Origin-Opener-Policy: same-origin

COOP kann Browser-Kontexte voneinander isolieren. Mozilla beschreibt den Header als Möglichkeit, zu steuern, ob verschiedene Top-Level-Dokumente innerhalb derselben Browsing Context Group ausgeführt werden.

Diese Header können für moderne Anwendungen sehr wertvoll sein.

Sie können allerdings ebenfalls externe Logins, Pop-ups, eingebettete Inhalte, APIs und externe Ressourcen beeinflussen.

Deshalb gehören sie eher in die Kategorie Advanced Security Hardening.

Website Security Header mit curl prüfen

Unter Linux, macOS und vielen Windows-Systemen reicht bereits curl.

Beispiel:

curl -I https://example.de

Du erhältst anschließend die HTTP Response Header.

Noch aussagekräftiger ist häufig ein normaler GET-Request, bei dem nur die Header ausgegeben werden:

curl -s -D - -o /dev/null https://example.de

Anschließend suchst du beispielsweise nach:

content-security-policy
strict-transport-security
x-content-type-options
x-frame-options
referrer-policy
permissions-policy

Security Header unter Windows mit PowerShell prüfen

Auch mit PowerShell lassen sich HTTP Header auslesen:

$response = Invoke-WebRequest -Uri "https://example.de"
$response.Headers

Alternativ kannst du auf aktuellen Windows-Systemen curl.exe verwenden:

curl.exe -I https://example.de

Für Administratoren eignet sich diese Methode hervorragend, um mehrere Websites automatisiert zu überprüfen.

Security Header direkt im Browser prüfen

Du benötigst nicht einmal ein zusätzliches Programm.

In Chrome, Edge oder Firefox:

1. Website öffnen.
2. Entwicklertools öffnen.
3. Zum Bereich Network / Netzwerk wechseln.
4. Seite neu laden.
5. Das Hauptdokument auswählen.
6. Response Headers anzeigen.

Dort findest du beispielsweise:

content-security-policy
strict-transport-security
x-frame-options
x-content-type-options

Besonders bei CSP-Problemen lohnt sich zusätzlich ein Blick in die Browser-Konsole. Blockierte Skripte oder Ressourcen werden dort häufig sichtbar.

Security Header mit Online-Tools testen

Wer keine Kommandozeile verwenden möchte, kann seine Website auch automatisch analysieren lassen.

Zwei bekannte Möglichkeiten sind:

Mozilla HTTP Observatory: Mozilla stellt mit dem HTTP Observatory einen Scanner bereit, der unter anderem CSP, HSTS und weitere Sicherheitskonfigurationen untersucht und Verbesserungsvorschläge liefert.

SecurityHeaders.com: SecurityHeaders.com konzentriert sich speziell auf die Analyse von HTTP Response Headern und ermöglicht einen schnellen Überblick über vorhandene und fehlende Security Header.

Ein gutes Testergebnis ist hilfreich – bedeutet aber nicht automatisch, dass eine Website insgesamt sicher ist.

Security Header sind nur eine Ebene der Web-Security.

Warum ein A+ Security-Header-Rating nicht automatisch eine sichere Website bedeutet

Das ist ein sehr wichtiger Punkt.

Eine Website kann perfekte Security Header besitzen und trotzdem beispielsweise:

• veraltete WordPress-Plugins einsetzen
• unsichere Passwörter verwenden
• SQL-Injection ermöglichen
• fehlerhafte Zugriffsrechte besitzen
• unsichere Session-Cookies verwenden
• anfällige APIs bereitstellen
• verwundbare JavaScript-Bibliotheken einsetzen

Security Header sind deshalb keine Sicherheitsgarantie.

Sie sind ein Bestandteil eines Defense-in-Depth-Konzepts.

Security Header unter Nginx konfigurieren

Bei Nginx können Header beispielsweise folgendermaßen ergänzt werden:

add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Strict-Transport-Security "max-age=31536000" always;

Eine CSP könnte zusätzlich beispielsweise lauten:

add_header Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self';" always;

Wichtig: Diese CSP ist nur ein Beispiel und darf nicht ungeprüft in ein Produktivsystem übernommen werden.

Gerade bei Nginx solltest du außerdem prüfen, welche Header tatsächlich am Client ankommen. Reverse Proxies, verschachtelte Locations, Loadbalancer oder CDNs können die endgültige Antwort beeinflussen.

Security Header unter Apache konfigurieren

Mit Apache und mod_headers ist beispielsweise folgende Konfiguration möglich:

<IfModule mod_headers.c>
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Strict-Transport-Security "max-age=31536000"
</IfModule>

Eine CSP könnte zusätzlich definiert werden:

Header always set Content-Security-Policy "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self';"

Auch hier gilt: Erst testen, dann produktiv aktivieren.

Security Header unter Microsoft IIS konfigurieren

Bei IIS lassen sich Header beispielsweise über die web.config hinzufügen:

<configuration>
<system.webServer>
<httpProtocol>
<customHeaders>
<add name="X-Content-Type-Options" value="nosniff" />
<add name="X-Frame-Options" value="SAMEORIGIN" />
<add name="Referrer-Policy" value="strict-origin-when-cross-origin" />
<add name="Strict-Transport-Security" value="max-age=31536000" />
</customHeaders>
</httpProtocol>
</system.webServer>
</configuration>

Alternativ können Header zentral über den IIS Manager oder auf vorgelagerten Reverse Proxies gesetzt werden.

Bei größeren Infrastrukturen ist eine zentrale Umsetzung häufig sinnvoll – beispielsweise auf Nginx, HAProxy, IIS ARR, Apache, Cloudflare, einem Application Gateway oder einem CDN. Wie ich ChatGPT ganz allgemein für solche Konfigurations- und Diagnoseaufgaben in der Linux-Administration einsetze, beschreibe ich in Wie ich ChatGPT für Linux-Administration nutze (Zum Artikel).

Entscheidend ist letztendlich nicht, wo der Header gesetzt wird. Entscheidend ist, welcher Header beim Browser tatsächlich ankommt.

Security Header hinter HAProxy oder Reverse Proxy prüfen

Besonders bei größeren Infrastrukturen gibt es häufig mehrere Ebenen:

Internet
↓
CDN / WAF
↓
HAProxy / Loadbalancer
↓
Nginx / IIS / Apache
↓
Webanwendung

Header können auf jeder dieser Ebenen hinzugefügt, überschrieben, entfernt oder doppelt ausgeliefert werden.

Deshalb solltest du niemals ausschließlich die Konfiguration des Backend-Servers kontrollieren.

Teste immer die öffentlich erreichbare URL.

Beispiel:

curl -s -D - -o /dev/null https://www.example.de

Damit überprüfst du die Antwort so, wie sie auch beim Besucher ankommt.

Typische Fehler bei Website Security Headern

Fehler 1: CSP einfach aus dem Internet kopieren

Jede Website verwendet andere Ressourcen. Eine fremde CSP passt deshalb fast nie exakt zur eigenen Anwendung.

Fehler 2: HSTS inklusive Subdomains sofort aktivieren

includeSubDomains kann alte Subdomains unerreichbar machen, wenn diese noch kein HTTPS unterstützen.

Fehler 3: HSTS Preload ohne Planung

Eine Preload-Konfiguration sollte erst eingesetzt werden, wenn der vollständige HTTPS-Betrieb dauerhaft sichergestellt ist.

Fehler 4: Nur die Startseite testen

Header können abhängig von URL, Anwendung, Backend, Virtual Host oder Reverse Proxy unterschiedlich sein. Teste deshalb beispielsweise auch /, /login, /admin, /api/, /shop/ und /kontakt.

Fehler 5: Nur nach vorhandenen Headern suchen

Ein vorhandener Header ist nicht automatisch ein guter Header.

Beispiel:

Content-Security-Policy: *

wäre zwar technisch eine Policy, würde aber kaum den gewünschten Schutz bieten.

Entscheidend ist deshalb sowohl: Ist der Header vorhanden? als auch: Ist sein Inhalt sinnvoll?

Empfohlene Security-Header-Baseline

Für eine klassische Website könnte eine erste Orientierung beispielsweise so aussehen:

Strict-Transport-Security: max-age=31536000
X-Content-Type-Options: nosniff
X-Frame-Options: SAMEORIGIN
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: geolocation=(), camera=(), microphone=()

Dazu sollte eine individuell auf die Website abgestimmte Content Security Policy kommen.

Noch einmal wichtig: Diese Werte sind keine universelle Copy-and-Paste-Konfiguration.

Webanwendungen mit externen APIs, Payment-Anbietern, eingebetteten Videos, SSO, Karten oder anderen Integrationen benötigen möglicherweise andere Einstellungen.

Das OWASP Secure Headers Project führt deshalb für die verschiedenen Security Header sowohl empfohlene Konfigurationen als auch deren jeweilige Einsatzbereiche auf.

Haben Security Header Auswirkungen auf SEO?

Diese Frage wird häufig falsch beantwortet.

CSP, X-Frame-Options oder Permissions-Policy sind keine magischen SEO-Ranking-Faktoren.

Du solltest Security Header deshalb nicht installieren, um vermeintlich einige Rankingpunkte zu gewinnen.

Anders sieht es beim grundsätzlichen sicheren Betrieb einer Website aus.

Google bezeichnet HTTPS als positives Signal und empfiehlt Websitebetreibern ausdrücklich die sichere Bereitstellung ihrer Seiten. In den aktuellen Hinweisen zur Page Experience fragt Google ebenfalls ausdrücklich danach, ob Seiten sicher ausgeliefert werden.

Der Zusammenhang lautet deshalb eher:

Security Header → bessere technische Absicherung → geringeres Risiko kompromittierter Inhalte → mehr Vertrauen und stabilerer Websitebetrieb → positive Grundlage für Nutzer und Suchmaschinen.

Eine gehackte Website mit Spam-Seiten, Malware oder manipulierten Weiterleitungen kann dagegen massive SEO-Probleme verursachen. Googles Spam-Richtlinien behandeln ausdrücklich auch durch Angreifer eingeschleuste Inhalte und Weiterleitungen.

Security ist deshalb definitiv ein Thema für SEO – nur eben nicht als einfacher „Header rein, Ranking hoch"-Trick.

Security Header regelmäßig überwachen

Ein einmaliger Test reicht langfristig nicht aus.

Websites verändern sich ständig: neue Plugins, neue Tracking-Systeme, neue APIs, Servermigrationen, CDN-Wechsel, Reverse-Proxy-Anpassungen, CMS-Updates, neue Subdomains.

Eine heute funktionierende Security-Konfiguration kann deshalb einige Monate später nicht mehr optimal sein.

Für geschäftskritische Systeme ist es sinnvoll, Header automatisiert zu überwachen. Beispielsweise mit curl in Kombination mit Cron, PowerShell, GitHub Actions, GitLab CI/CD, Jenkins, Checkmk, Zabbix oder Nagios.

Damit kann beispielsweise geprüft werden, ob Strict-Transport-Security, Content-Security-Policy und X-Content-Type-Options weiterhin vorhanden sind.

Website Security Header Checkliste

Vor dem Abschluss solltest du folgende Punkte prüfen:

• Website vollständig über HTTPS erreichbar
• HTTP sauber auf HTTPS umgeleitet
• Strict-Transport-Security geprüft
• Auswirkungen von includeSubDomains verstanden
• HSTS Preload nur bewusst eingesetzt
• X-Content-Type-Options: nosniff vorhanden
• Clickjacking-Schutz geprüft
• X-Frame-Options beziehungsweise CSP frame-ancestors geprüft
• Referrer-Policy definiert
• Permissions-Policy an benötigte Browserfunktionen angepasst
• Content Security Policy individuell erstellt
• CSP zunächst getestet
• externe Skripte und APIs berücksichtigt
• Browser-Konsole auf CSP-Verstöße kontrolliert
• öffentlich erreichbare URL statt nur Backend getestet
• mehrere Unterseiten überprüft
• Header nach Änderungen erneut getestet

Häufige Fragen zu Website Security Headern

Was sind Security Header?

Security Header sind HTTP Response Header, mit denen ein Webserver dem Browser zusätzliche Sicherheitsregeln übermittelt. Sie können beispielsweise festlegen, welche Skripte geladen werden dürfen oder ob eine Website ausschließlich über HTTPS erreichbar sein soll.

Wie kann ich Security Header prüfen?

Am einfachsten funktioniert dies mit:

curl -I https://example.de

Alternativ können die Browser-Entwicklertools, Mozilla HTTP Observatory oder SecurityHeaders.com verwendet werden.

Welcher Security Header ist am wichtigsten?

Das lässt sich nicht pauschal auf einen einzelnen Header reduzieren. Besonders relevant sind jedoch HSTS, Content Security Policy und X-Content-Type-Options. Die optimale Kombination hängt von der jeweiligen Webanwendung ab.

Was macht eine Content Security Policy?

Eine CSP definiert, welche Ressourcen und Ursprünge eine Website verwenden darf. Dadurch kann insbesondere das Risiko unerwünschter oder eingeschleuster Skripte reduziert werden.

Was macht HSTS?

HSTS weist Browser an, eine Domain künftig ausschließlich über HTTPS aufzurufen. Dadurch kann unter anderem verhindert werden, dass ein Benutzer versehentlich wieder auf eine unverschlüsselte HTTP-Verbindung zurückfällt.

Kann eine falsche CSP meine Website beschädigen?

Ja. Eine zu restriktive Policy kann JavaScript, Stylesheets, Fonts, APIs, Videos oder Tracking-Systeme blockieren. Deshalb sollte eine CSP vor der produktiven Aktivierung gründlich getestet werden.

Fazit: Security Header gehören zum technischen Grundschutz einer Website

Eine Website nur mit HTTPS zu betreiben ist wichtig – aber damit endet moderne Website-Sicherheit nicht.

Security Header geben Administratoren und Entwicklern zusätzliche Möglichkeiten, direkt im Browser Schutzmechanismen durchzusetzen.

Besonders relevant sind: Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options, Referrer-Policy und Permissions-Policy.

Mit einem einfachen:

curl -I https://deine-domain.de

kannst du innerhalb weniger Sekunden einen ersten Überblick gewinnen.

Danach beginnt allerdings die eigentliche Arbeit: Nicht möglichst viele Header setzen, sondern die richtigen Header mit sinnvollen Regeln konfigurieren.

Insbesondere bei CSP und HSTS gilt: Eine getestete und zur eigenen Infrastruktur passende Konfiguration ist wertvoller als eine vermeintlich perfekte Vorlage aus dem Internet.

Wer seine Website professionell betreibt, sollte Security Header deshalb genauso selbstverständlich kontrollieren wie SSL-Zertifikate, Updates, Backups und Serverlogs.

Weiterführende Themen

SPF, DKIM und DMARC einfach erklärt – E-Mail-Sicherheit prüfen (Zum Artikel)

MCP Server sicher betreiben: Rechte, Tools und Risiken erklärt (Zum Artikel)

Wann du KI-Outputs im Admin-Alltag hinterfragen musst (Zum Artikel)

Wie ich ChatGPT für Linux-Administration nutze (Zum Artikel)

Quellen und weiterführende technische Dokumentation

Mozilla MDN – Content Security Policy. Mozilla MDN – Strict-Transport-Security. OWASP – HTTP Security Response Headers Cheat Sheet. OWASP Secure Headers Project. Google Search Central – HTTPS und sichere Website-Auslieferung. Mozilla HTTP Observatory – automatisierter Security-Header-Test.

Stand: August 2026.