Zurück zum Blog

Security-Header: HSTS, CSP, X-Frame-Options und andere

· 7 Min. Lesezeit

Kurz gesagt: Security-HTTP-Header sind Zeilen, die der Server jeder HTTP-Antwort hinzufügt, um dem Browser zu sagen, wie er mit Ihrer Seite umgehen soll. Korrekt gesetzt eliminieren sie ganze Klassen von Angriffen (XSS, Clickjacking, MITM) - und sind kostenlos.

Kurz gesagt: Security-HTTP-Header sind Zeilen, die der Server jeder HTTP-Antwort hinzufügt, um dem Browser zu sagen, wie er mit Ihrer Seite umgehen soll. Korrekt gesetzt eliminieren sie ganze Klassen von Angriffen (XSS, Clickjacking, MITM) - und sind kostenlos.

Warum sie wichtig sind

Eine Anwendung kann backend-seitig perfekt sicher sein, aber ohne richtige Header dennoch anfällig für Browser-seitige Angriffe: Cross-Site Scripting (XSS), Clickjacking, Protocol Downgrade, MIME Confusion. Security-Header verschieben die Verteidigung in den Browser.

Strict-Transport-Security (HSTS)

Erzwingt HTTPS für alle zukünftigen Besuche. Nach dem ersten HTTPS-Besuch merkt sich der Browser die Domain und schreibt selbst jeden http://-Link auf https:// um, auch wenn der Benutzer auf eine schlechte Antwort klickt.

Strict-Transport-Security: max-age=63072000; includeSubDomains; preload
  • max-age=63072000 = gilt 2 Jahre
  • includeSubDomains = die Regel gilt auch für alle Subdomains (Achtung: wenn Sie eine HTTP-only Subdomain haben, bricht sie)
  • preload = ermöglicht Aufnahme in die HSTS-Preload-Liste, die in Chrome / Firefox / Safari eingebaut ist

Achtung: HSTS mit preload braucht 6+ Monate für die Entfernung aus der Liste. Schließen Sie preload nicht ein, bevor Sie überprüft haben, dass HTTPS stabil auch für alle Subdomains funktioniert.

Content-Security-Policy (CSP)

Der mächtigste, aber auch am schwierigsten zu konfigurierende Header. Whitelistet, von wo der Browser Skripte, Styles, Bilder, iFrames laden darf. Ohne CSP kann ein Angreifer, der einen <script>-Tag injizieren kann, beliebiges JS ausführen - mit CSP nur Code aus genehmigten Quellen.

Content-Security-Policy: default-src 'self'; script-src 'self' 'sha256-...'; img-src 'self' data: https://cdn.example.com; style-src 'self' 'unsafe-inline'; frame-ancestors 'none'

Übliche Direktiven:

  • default-src 'self' = als Default nur Ressourcen aus meiner Domain erlauben
  • script-src = JS-Quellen (Hash oder Nonce für Inline-Skripte angeben)
  • style-src = CSS-Quellen
  • img-src = Bilder
  • connect-src = AJAX, WebSocket, EventSource
  • frame-ancestors 'none' = niemand darf die Seite in iFrame einbetten (besser als X-Frame-Options)
  • report-uri /csp-report = Browser sendet JSON bei jeder Verletzung (Sie fangen es im Backend ab und loggen es)

X-Frame-Options

Ältere Alternative zu frame-ancestors. Verhindert Clickjacking - Angreifer bettet Ihre Seite als iFrame ein und überlagert sie mit unsichtbaren Buttons.

X-Frame-Options: DENY

Werte: DENY (niemand), SAMEORIGIN (nur meine Domain), ALLOW-FROM uri (deprecated).

X-Content-Type-Options

X-Content-Type-Options: nosniff

Schaltet MIME-Sniffing aus - der Browser wird den Content-Type respektieren, den der Server zurückgab. Ohne das kann ein Angreifer eine Datei mit falschem Typ hochladen (z. B. ein Bild, das eigentlich HTML mit Skript ist) und der Browser kann es als Webseite ausführen.

Referrer-Policy

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

Steuert, wie viel Informationen über die vorherige Seite der Browser im Referer-Header beim Klick sendet. Default in modernen Browsern ist bereits strict-origin-when-cross-origin, aber der explizite deklarative Header sichert Konsistenz.

Permissions-Policy

Schaltet APIs ab, die Sie nicht brauchen - Kamera, Mikrofon, GPS, Geolocation. Angreifer kann über XSS diese APIs nicht anfordern.

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

Praktische nginx-Konfiguration

server {
  listen 443 ssl http2;
  server_name example.com;

  add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
  add_header X-Content-Type-Options "nosniff" always;
  add_header X-Frame-Options "DENY" always;
  add_header Referrer-Policy "strict-origin-when-cross-origin" always;
  add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;

  # CSP ist umfangreich - definieren Sie sie nach Ihrer Anwendung
  add_header Content-Security-Policy "default-src 'self'; script-src 'self'; ..." always;
}

Schlüssel ist always - ohne das lässt nginx Header bei Error-Responses (4xx, 5xx) aus.

Audit des aktuellen Stands

Am einfachsten über ein Online-Tool. Unser Header-Check zeigt Ihnen, welche Header fehlen und welche falsch sind. Für gründliches Audit gibt securityheaders.com auch eine A-F-Note.

Fazit

Security-Header sind eine der besten Investitionen im Verhältnis Aufwand zu Gewinn im Security-Bereich - typisch eine halbe Stunde Setup im Reverse Proxy gegen eine ganze Kategorie Browser-seitiger Angriffe. Audit einmal pro halbes Jahr im Rahmen regulärer Wartung ist vernünftiges Minimum.

Kostenloses Security-Headers-Audit

Ohne Registrierung, Ergebnis in drei Sekunden.

Website testen →


ePulz.io kostenlos testen - 7 Tage, ohne Kreditkarte.

Konto erstellen