Security Headers — Website-Sicherheit richtig konfigurieren

Warum Security Headers wichtig sind

Security Headers sind HTTP-Antwort-Header, die der Webserver bei jeder Anfrage mitsendet. Sie weisen den Browser an, bestimmte Sicherheitsmechanismen zu aktivieren — etwa das Blockieren von eingebetteten Inhalten aus fremden Quellen oder das Erzwingen verschlüsselter Verbindungen.

Ohne passende Security Headers kann eine Website anfälliger für Angriffe wie Cross-Site-Scripting (XSS), Clickjacking oder Man-in-the-Middle-Angriffe sein. Das Bundesamt für Sicherheit in der Informationstechnik (BSI) empfiehlt in seinen IT-Grundschutz-Bausteinen die Konfiguration dieser Header als grundlegende Schutzmaßnahme.

Die wichtigsten Security Headers im Überblick

Content Security Policy (CSP)

Die Content Security Policy ist einer der wirksamsten Security Headers. Sie legt fest, aus welchen Quellen ein Browser Inhalte laden darf — Skripte, Stylesheets, Bilder, Fonts und mehr.

Beispiel:

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.example.com

Dieser Header erlaubt nur Skripte von der eigenen Domain und einem vertrauenswürdigen CDN. Alle anderen Quellen werden blockiert. Das kann Cross-Site-Scripting-Angriffe erheblich erschweren.

Empfehlung: Mit einer restriktiven CSP beginnen und bei Bedarf schrittweise Quellen hinzufügen. Das OWASP Secure Headers Project bietet hilfreiche Vorlagen.

HTTP Strict Transport Security (HSTS)

HSTS weist den Browser an, die Website ausschließlich über HTTPS aufzurufen — auch wenn der Nutzer HTTP eingibt. Das verhindert sogenannte Downgrade-Angriffe, bei denen ein Angreifer die Verbindung auf unverschlüsseltes HTTP umleiten könnte.

Beispiel:

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

Wichtige Parameter:

• max-age: Dauer in Sekunden, für die der Browser HTTPS erzwingt (empfohlen: mindestens 1 Jahr)
• includeSubDomains: Gilt auch für alle Subdomains
• preload: Ermöglicht die Aufnahme in die HSTS-Preload-Liste der Browser

X-Frame-Options

Dieser Header schützt vor Clickjacking-Angriffen. Clickjacking bedeutet: Eine fremde Website bettet Ihre Seite in einem unsichtbaren iframe ein, und der Nutzer klickt unwissentlich auf Elemente Ihrer Seite.

Mögliche Werte:

• DENY — Seite darf in keinem iframe eingebettet werden
• SAMEORIGIN — Nur Einbettung von der gleichen Domain erlaubt

Empfehlung: DENY verwenden, sofern keine eigenen iframes benötigt werden. Alternativ kann auch der modernere frame-ancestors-Directive in der CSP verwendet werden.

X-Content-Type-Options

Verhindert, dass der Browser den MIME-Typ einer Datei “errät” (MIME-Sniffing). Ohne diesen Header könnte ein Browser eine als Bild getarnte Datei als JavaScript ausführen.

Konfiguration:

X-Content-Type-Options: nosniff

Dieser Header hat nur einen gültigen Wert und sollte auf jeder Website gesetzt sein.

Referrer-Policy

Steuert, welche Referrer-Informationen bei einem Klick auf einen Link an die Zielseite übermittelt werden. Ohne passende Einstellung kann die vollständige URL — möglicherweise inklusive sensibler Parameter — an Dritte weitergegeben werden.

Empfohlene Werte:

• strict-origin-when-cross-origin — Bei externen Links wird nur die Domain übermittelt, nicht der vollständige Pfad
• no-referrer — Keine Referrer-Informationen werden gesendet

Permissions-Policy

Die Permissions-Policy (vormals Feature-Policy) legt fest, welche Browser-APIs eine Website nutzen darf — etwa Kamera, Mikrofon, Geolocation oder Payment.

Beispiel:

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

Dieses Beispiel deaktiviert alle genannten APIs. Das empfiehlt sich für Websites, die diese Funktionen nicht benötigen — es verhindert, dass eingebettete Drittanbieter-Skripte unbemerkt auf sensible Gerätefunktionen zugreifen.

Subresource Integrity (SRI)

SRI ist streng genommen kein HTTP-Header, sondern ein HTML-Attribut für <script>- und <link>-Tags. Es stellt sicher, dass extern geladene Ressourcen (z. B. von einem CDN) nicht manipuliert wurden.

Beispiel:

<script src="https://cdn.example.com/lib.js"
        integrity="sha384-abc123..."
        crossorigin="anonymous"></script>

Der Browser prüft den Hash der heruntergeladenen Datei gegen den angegebenen Wert. Stimmt er nicht überein, wird die Datei nicht ausgeführt.

TLS-Version und Verschlüsselung

Die Transportverschlüsselung (TLS) ist die Grundlage jeder sicheren Verbindung — warum ein SSL-Zertifikat Pflicht ist, erfahren Sie in unserem separaten Ratgeber. Ältere Protokollversionen wie TLS 1.0 und 1.1 gelten als unsicher und sollten deaktiviert werden.

Empfehlung:

• Mindestens TLS 1.2 verwenden
• Bevorzugt TLS 1.3 — schneller und sicherer
• TLS 1.0 und 1.1 auf dem Server deaktivieren

Das BSI empfiehlt in der Technischen Richtlinie TR-02102-2 die Verwendung von TLS 1.2 mit bestimmten Cipher Suites oder TLS 1.3.

DNSSEC

DNSSEC (Domain Name System Security Extensions) schützt vor DNS-Manipulation. Ohne DNSSEC könnte ein Angreifer DNS-Antworten fälschen und Besucher auf eine gefälschte Version Ihrer Website umleiten.

Was DNSSEC tut:

• Signiert DNS-Einträge kryptografisch
• Der Browser kann prüfen, ob die DNS-Antwort authentisch ist

Die Aktivierung erfolgt über den Domain-Registrar und den DNS-Provider. Viele große Anbieter unterstützen DNSSEC mittlerweile standardmäßig.

Checkliste: Security Headers prüfen

1. CSP konfiguriert? — Definiert erlaubte Quellen für Skripte, Styles und andere Ressourcen
2. HSTS aktiv? — Erzwingt HTTPS mit ausreichendem max-age
3. X-Frame-Options gesetzt? — Schützt vor Clickjacking
4. X-Content-Type-Options: nosniff — Verhindert MIME-Sniffing
5. Referrer-Policy definiert? — Kontrolliert Referrer-Informationen
6. Permissions-Policy gesetzt? — Deaktiviert nicht benötigte Browser-APIs
7. SRI für externe Skripte? — Prüft Integrität externer Ressourcen
8. TLS 1.2+ erzwungen? — Keine veralteten Protokolle
9. DNSSEC aktiviert? — Schutz vor DNS-Manipulation

Tipp: Mit einem kostenlosen Website-Check können Sie prüfen, welche Security Headers Ihre Website bereits setzt — und wo möglicherweise Handlungsbedarf besteht. Einen umfassenden Überblick über alle Prüfbereiche bietet unser Ratgeber zum rechtssicheren Website-Check.

Häufige Fragen

Sind Security Headers Pflicht?

Es gibt in Deutschland kein Gesetz, das bestimmte Security Headers explizit vorschreibt. Allerdings verlangt die DSGVO in Art. 32 “geeignete technische und organisatorische Maßnahmen” zum Schutz personenbezogener Daten — unsere DSGVO-Checkliste für Websites zeigt, welche weiteren Anforderungen gelten. Security Headers können als solche Maßnahme betrachtet werden. Auch das BSI empfiehlt ihre Konfiguration im Rahmen des IT-Grundschutzes.

Kann ich Security Headers selbst einrichten?

Grundsätzlich ja — die Konfiguration erfolgt auf dem Webserver (Apache, Nginx) oder über einen Reverse Proxy (z. B. Cloudflare). Für Content-Management-Systeme wie WordPress gibt es Plugins, die die Einrichtung vereinfachen. Bei komplexeren Setups empfiehlt es sich, einen IT-Berater hinzuzuziehen.

Können Security Headers meine Website beeinträchtigen?

Eine zu restriktive Content Security Policy kann dazu führen, dass eingebundene Dienste nicht mehr funktionieren — etwa Analytics-Tools, eingebettete Videos oder externe Fonts. Es empfiehlt sich, nach der Aktivierung die Browser-Konsole auf Fehlermeldungen zu prüfen und die CSP schrittweise anzupassen.