Security Policy Header

Ein Security Policy Header wird verwendet, um Sicherheitsrichtlinien für eine Website festzulegen. Der häufigste Header dieser Art ist der Content Security Policy (CSP)-Header, aber es gibt auch andere Header wie Strict-Transport-Security (HSTS) und Referrer-Policy, die ebenfalls wichtige Sicherheitsrichtlinien für Webanwendungen definieren.

Hier ein Überblick, wie diese Header aufgebaut sind:

1. Content Security Policy (CSP)

Die Content Security Policy (CSP) ist eine der wichtigsten Sicherheitsrichtlinien, die angibt, von welchen Quellen Ressourcen (wie Skripte, Bilder, Stylesheets) geladen werden dürfen.

Beispiel für CSP:

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com; object-src 'none'; style-src 'self' 'unsafe-inline'; img-src 'self' https://trusted-image-cdn.com; connect-src 'self' https://api.example.com;

Erklärung:

  • default-src 'self';: Standardmäßig dürfen Ressourcen nur von der gleichen Domain geladen werden ('self').
  • script-src 'self' https://trusted-cdn.com;: Skripte dürfen nur von der eigenen Domain und einem vertrauenswürdigen CDN geladen werden.
  • object-src 'none';: Das Laden von Plugins oder Objekten (z. B. Flash) wird vollständig deaktiviert.
  • style-src 'self' 'unsafe-inline';: Stylesheets dürfen nur von der eigenen Domain und Inline-Stilen geladen werden.
  • img-src 'self' https://trusted-image-cdn.com;: Bilder dürfen nur von der eigenen Domain und einem vertrauenswürdigen CDN geladen werden.
  • connect-src 'self' https://api.example.com;: XHR, WebSockets und ähnliche Verbindungen dürfen nur zur eigenen Domain und einer vertrauenswürdigen API gemacht werden.

Optionen:

  • 'self': Beschränkt die Quelle auf die eigene Domain.
  • 'none': Verhindert das Laden jeglicher Inhalte von dieser Quelle.
  • 'unsafe-inline': Erlaubt das Laden von Inline-Skripten (nicht empfohlen, da unsicher).
  • 'unsafe-eval': Erlaubt die Verwendung von eval() (wird oft aus Sicherheitsgründen blockiert).

CSP-Header für Sub-Resource Integrity:

Content-Security-Policy: script-src 'self' https://example.com; require-trusted-types-for 'script'; trusted-types my-policy;

2. Strict-Transport-Security (HSTS)

Der HSTS-Header weist Browser an, nur über HTTPS auf eine Website zuzugreifen. Dies verhindert, dass Angreifer eine Verbindung über HTTP erzwingen (z. B. durch „SSL Stripping“).

Beispiel für HSTS:

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

Erklärung:

  • max-age=31536000;: Die Anzahl der Sekunden, die der Browser HTTPS erzwingen soll (in diesem Fall 1 Jahr).
  • includeSubDomains;: Die Richtlinie gilt für alle Subdomains.
  • preload: Diese Website kann in die HSTS Preload-Liste aufgenommen werden, die von Browsern wie Chrome, Firefox und Safari verwendet wird.

3. Referrer-Policy

Der Referrer-Policy-Header steuert, wie der Referer-Header (der die URL der Seite enthält, von der ein Besucher kommt) gesendet wird. Dies ist besonders wichtig, um die Privatsphäre der Nutzer zu schützen.

Beispiel für Referrer-Policy:

Referrer-Policy: no-referrer-when-downgrade

Erklärung:

  • no-referrer-when-downgrade: Der Referer wird nicht gesendet, wenn die Anfrage von HTTPS zu HTTP wechselt. Andernfalls wird der Referer übermittelt.
  • Weitere Optionen:
    • no-referrer: Kein Referer wird gesendet.
    • origin: Nur der Ursprung (z. B. https://example.com) wird gesendet, ohne den Pfad.
    • unsafe-url: Der vollständige Referer wird immer gesendet.

4. X-Content-Type-Options

Dieser Header verhindert das „MIME Sniffing“ von Browsern, was das Risiko verringert, dass gefährlicher Inhalt (z. B. JavaScript) ausgeführt wird, wenn der Server fälschlicherweise einen anderen MIME-Typ angibt.

Beispiel:

X-Content-Type-Options: nosniff

Erklärung:

  • nosniff: Verhindert, dass Browser den MIME-Typ einer Datei erraten (Sniffing), was potenziell gefährlich sein könnte.

5. X-Frame-Options

Der X-Frame-Options-Header verhindert, dass eine Webseite in einem iFrame eingebettet wird, was eine häufige Angriffsmethode für Clickjacking darstellt.

Beispiel:

X-Frame-Options: DENY

Erklärung:

  • DENY: Die Seite kann in keinem Frame oder iFrame angezeigt werden.
  • SAMEORIGIN: Die Seite kann nur auf der gleichen Domain in einem iFrame angezeigt werden.

6. Permissions-Policy

Der Permissions-Policy-Header kontrolliert, welche Web-APIs und Funktionen der Browser einer Webseite zur Verfügung stellt.

Beispiel:

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

Erklärung:

  • geolocation=(self): Erlaubt den Zugriff auf die Geolokalisierung nur von der eigenen Domain.
  • camera=(), microphone=(): Verhindert den Zugriff auf die Kamera und das Mikrofon.

Zusammenfassung der wichtigsten Sicherheits-Header:

Header Zweck Beispiel
Content-Security-Policy Steuerung, von welchen Quellen Inhalte geladen werden default-src 'self'; script-src 'self' https://trusted.com
Strict-Transport-Security (HSTS) Erzwingt HTTPS für eine Website und ihre Subdomains max-age=31536000; includeSubDomains; preload
Referrer-Policy Kontrolle über den Referer-Header no-referrer-when-downgrade
X-Content-Type-Options Verhindert MIME Sniffing nosniff
X-Frame-Options Verhindert Clickjacking DENY
Permissions-Policy Kontrolle über Web-API und Funktionen geolocation=(self)

Diese Header können direkt auf deinem Webserver (Apache, Nginx) oder via PHP (für CSP und andere Sicherheits-Header) gesetzt werden. Bei einer WordPress-Instanz sind sie meist direkt in der Serverkonfiguration oder via Plugin steuerbar. Wenn du weitere Informationen zu einem der Header benötigst oder Hilfe beim Setzen der Header in deiner Konfiguration benötigst, lass es mich wissen!

 

Quelle: Chatgpt.com, 22.07.2025