Sicherheitsheader und HTTPS

• Website-Sicherheit
• Aktualisiert: 04.10.2026
• Ca. 8 Min. Lesezeit

Umsetzung in vier Schritten

1. 1

   Leiten Sie den gesamten Datenverkehr auf HTTPS um

   Bleibt die http://-Adresse der Website nach der Installation des Zertifikats erreichbar, können sich Besucher weiterhin unverschlüsselt verbinden. Leiten Sie alle Anfragen mit einer permanenten Weiterleitung (301) auf HTTPS um.

   .htaccess (Apache)

   RewriteEngine On
   
   # Für Anfragen, die direkt beim Server ankommen
   RewriteCond %{HTTPS} off
   RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]
   
   # Hinter einem CDN / Reverse Proxy statt der obigen Bedingung:
   # RewriteCond %{HTTP:X-Forwarded-Proto} =http
   # RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

   Steht Ihre Website hinter einem CDN oder einem Reverse Proxy (z. B. Cloudflare), sieht Ihr Server die Anfrage möglicherweise als HTTP, und diese Regel kann zu einer Endlosweiterleitung führen. Richten Sie die Weiterleitung in diesem Fall im CDN-Panel ein oder verwenden Sie in der Bedingung den Header X-Forwarded-Proto.

   : Vergrößern

2. 2

   Setzen Sie die grundlegenden Header

   Der folgende Block enthält Header, die sich bei nahezu jeder Website gefahrlos setzen lassen. Fügen Sie ihn in die .htaccess-Datei im Web-Root ein.

   .htaccess (Apache)

   <IfModule mod_headers.c>
       # Nur in HTTPS-Antworten: Der Browser soll sich mit dieser Website immer über HTTPS verbinden.
       # Zuerst mit max-age=300 testen; ohne Probleme auf 31536000 (1 Jahr) erhöhen.
       Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains" "expr=%{HTTPS} == 'on'"
   
       # Dateityp nicht erraten
       Header always set X-Content-Type-Options "nosniff"
   
       # Anzeige im Frame anderer Websites
       Header always set X-Frame-Options "SAMEORIGIN"
   
       # An andere Websites nur die Domain weitergeben
       Header always set Referrer-Policy "strict-origin-when-cross-origin"
   
       # Nicht genutzte Browserfunktionen abschalten
       Header always set Permissions-Policy "geolocation=(), camera=(), microphone=(), payment=()"
   </IfModule>

   : Vergrößern

3. 3

   Starten Sie die CSP im Report-Only-Modus

   Die Content-Security-Policy ist der wirkungsvollste Header, verlangt aber auch die meiste Sorgfalt. Setzen Sie sie zunächst unter dem Namen Content-Security-Policy-Report-Only: Es wird nichts blockiert, Verstöße erscheinen in der Browserkonsole. Erst wenn Sie die Verstöße behoben haben, setzen Sie die Richtlinie durch.

   : Vergrößern

4. 4

   Überprüfen Sie das Ergebnis

   Wählen Sie in den Entwicklertools des Browsers im Tab „Netzwerk“ die Anfrage für die Seite aus und sehen Sie sich die Antwort-Header an, oder rufen Sie die Header über die Kommandozeile ab. Kontrollieren Sie, dass die Header nicht nur auf der Startseite, sondern auch auf Fehlerseiten und Unterseiten gesendet werden.

   Kommandozeile

   # Antwort-Header anzeigen (mit Ihrer eigenen Domain)
   curl -sI https://www.example.com/
   
   # Prüfen, ob die HTTP-Adresse auf HTTPS umgeleitet wird
   curl -sI http://www.example.com/ | grep -i -E "^(HTTP|location)"

   : Vergrößern

Anzeichen: Woran erkennt man fehlende Header?

• Die http://-Adresse der Website öffnet sich, ohne auf HTTPS umgeleitet zu werden.
• In der Browserkonsole erscheinen Warnungen zu „gemischten Inhalten“ (Mixed Content): Die HTTPS-Seite lädt Bilder oder Skripte über HTTP.
• In den Antwort-Headern fehlen Strict-Transport-Security, X-Content-Type-Options oder Content-Security-Policy.
• Ihre Website lässt sich innerhalb einer anderen Website als Frame (iframe) öffnen.
• In der Antwort verraten X-Powered-By oder ein ausführlicher Server-Header die Versionsnummer.

Die Header im Einzelnen

Strict-Transport-Security (HSTS)

Der Header weist den Browser an, sich für die angegebene Dauer mit dieser Domain ausschließlich über HTTPS zu verbinden. Selbst wenn der Benutzer die Adresse mit http:// eingibt, wandelt der Browser die Anfrage vor dem Senden in HTTPS um; so wird verhindert, dass der unverschlüsselte Moment der ersten Anfrage von jemandem ausgenutzt wird, der sich in die Verbindung einschaltet.

• Er darf nur in HTTPS-Antworten gesendet werden.
• Testen Sie zunächst mit einer kurzen Dauer (z. B. max-age=300); treten keine Probleme auf, erhöhen Sie auf ein Jahr (31536000).
• includeSubDomains schließt alle Subdomains ein. Vergewissern Sie sich vorher, dass Sie keine Subdomain haben, die HTTPS nicht unterstützt.
• preload dient dazu, die Domain in die fest eingebaute Liste der Browser aufnehmen zu lassen, und lässt sich nur schwer rückgängig machen; setzen Sie es nicht, wenn Sie nicht sicher sind.

X-Content-Type-Options

Der Wert nosniff verhindert, dass der Browser den Typ einer Datei anhand ihres Inhalts errät. So wird zum Beispiel verhindert, dass eine als Bild hochgeladene Datei wie ein Skript interpretiert wird. Nebenwirkungen gibt es so gut wie keine; der Header sollte auf jeder Website gesetzt sein.

X-Frame-Options und frame-ancestors

Diese Header verhindern, dass Ihre Website im Frame einer anderen Website angezeigt wird. Das schützt davor, dass der Benutzer über einen unsichtbaren Frame unbemerkt zu einem Klick verleitet wird (Clickjacking). SAMEORIGIN erlaubt das Einbetten nur durch Ihre eigene Website. Das zeitgemäße Gegenstück ist die CSP-Direktive frame-ancestors; beide zusammen zu senden, deckt alte und neue Browser ab.

Referrer-Policy

Der Header legt fest, welche Adressinformation der Browser weitergibt, wenn ein Besucher von Ihrer Website zu einer anderen wechselt. strict-origin-when-cross-origin ist ein ausgewogener Wert: An andere Websites geht nur Ihre Domain, nicht aber der Seitenpfad und die Parameter.

Permissions-Policy

Der Header legt fest, ob die Seite und die darin eingebetteten Frames Browserfunktionen wie Kamera, Mikrofon oder Standort nutzen dürfen. Funktionen abzuschalten, die Sie nicht verwenden, verhindert, dass ein fremdes, in die Seite gelangtes Skript sie anfordert. Gibt es auf Ihrer Website eine Karten- oder Standortfunktion, lassen Sie die betreffende Berechtigung für Ihre eigene Quelle aktiviert.

Content-Security-Policy Schritt für Schritt

Die CSP definiert, aus welchen Quellen die Seite Inhalte laden darf. Die wichtigsten Direktiven:

• default-src: Standardquelle für alle Typen, die in den übrigen Direktiven nicht genannt sind.
• script-src: Quellen, aus denen Skripte geladen werden dürfen. Diese Direktive liefert den eigentlichen Schutz gegen XSS.
• style-src, img-src, font-src, connect-src: Stylesheets, Bilder, Schriftarten und Hintergrundanfragen.
• frame-ancestors: Wer die Seite in einen Frame einbetten darf.
• object-src 'none' und base-uri 'self': Verhindern alte Plugin-Inhalte und die Manipulation des <base>-Tags.
• form-action: Adressen, an die Formulare gesendet werden dürfen.

Eine Richtlinie im Report-Only-Modus für den Einstieg:

<IfModule mod_headers.c>
    Header always set Content-Security-Policy-Report-Only "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src 'self' data:; connect-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'self'"
</IfModule>

Passen Sie die Richtlinie anhand der Verstöße in der Konsole an: Tragen Sie die externen Quellen, die Sie verwenden (Schriftarten, Analyse, Karten), einzeln in die jeweilige Direktive ein. Inline-Skripte und Event-Attribute wie onclick in eigene Dateien auszulagern, ermöglicht es Ihnen, den Wert 'unsafe-inline' aus der Direktive script-src zu entfernen; darin liegt der eigentliche Wert der CSP gegen XSS. Treten keine Verstöße mehr auf, schalten Sie den Header in den durchsetzenden Modus:

<IfModule mod_headers.c>
    # Nachdem die Verstöße behoben sind: dieselbe Richtlinie, diesmal durchgesetzt
    Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline' https://fonts.googleapis.com; font-src 'self' https://fonts.gstatic.com; img-src 'self' data:; connect-src 'self'; object-src 'none'; base-uri 'self'; form-action 'self'; frame-ancestors 'self'"
</IfModule>

Für Inline-Skripte, die sich nicht auslagern lassen, kann ein nonce-Wert verwendet werden, der bei jeder Antwort neu erzeugt wird; in diesem Fall sendet PHP den Header.

<?php
// Bei jeder Antwort wird ein neuer Nonce erzeugt
$nonce = base64_encode(random_bytes(16));
header("Content-Security-Policy: default-src 'self'; script-src 'self' 'nonce-$nonce'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'");
?>
<script nonce="<?= htmlspecialchars($nonce, ENT_QUOTES, 'UTF-8') ?>">
    // Nur Inline-Skripte mit diesem Nonce-Wert werden ausgeführt
    document.documentElement.classList.add('js');
</script>

Versionsangaben reduzieren

Dass in den Antwort-Headern die PHP- und die Serverversion sichtbar sind, ist für sich genommen keine Schwachstelle, liefert automatisierten Scans aber unnötige Informationen. Für PHP entfernt die Einstellung expose_php = Off den Header X-Powered-By. Die Ausführlichkeit des Server-Headers von Apache wird in der Serverkonfiguration mit ServerTokens verringert; beim Shared Hosting liegt diese Einstellung beim Anbieter.

<IfModule mod_headers.c>
    Header always unset X-Powered-By
    Header unset X-Powered-By
</IfModule>

# In php.ini oder .user.ini:
# expose_php = Off

Der eigentliche Schutz besteht nicht darin, die Version zu verbergen, sondern darin, sie aktuell zu halten.

Häufige Fehler

• HSTS mit langer Laufzeit und ungetestet aktivieren: Tritt ein Zertifikatsproblem auf, kommen Besucher überhaupt nicht mehr auf die Website; bis zum Ablauf der Laufzeit lässt sich das nicht zurücknehmen.
• In der CSP alles erlauben: Eine Richtlinie wie script-src * 'unsafe-inline' 'unsafe-eval' bietet keinen Schutz.
• Header nur in PHP senden: Bei Bildern, Fehlerseiten und statischen Dateien fehlen die Header dann. Sie in der Serverkonfiguration zu definieren, deckt mehr ab.
• Gemischte Inhalte stehen lassen: Ändern Sie in den Templates und in den Inhalten der Datenbank Ihre eigenen Adressen, die mit http:// beginnen, auf https://.
• Die Cookies vergessen: Geben Sie dem Sitzungs-Cookie nach der Umstellung auf HTTPS das Flag Secure. Siehe Login- und Sitzungssicherheit.

Checkliste

• HTTP-Anfragen werden per 301 auf HTTPS umgeleitet; es gibt keine Weiterleitungsschleife.
• Das Zertifikat ist gültig und wird automatisch erneuert.
• Es gibt keine Warnungen zu gemischten Inhalten.
• HSTS wurde mit kurzer Laufzeit getestet und danach verlängert.
• X-Content-Type-Options: nosniff ist gesetzt.
• Das Einbetten in Frames ist mit X-Frame-Options und frame-ancestors eingeschränkt.
• Referrer-Policy und Permissions-Policy sind gesetzt.
• Die CSP läuft mindestens im Report-Only-Modus; die Verstöße werden ausgewertet.
• Die Header werden auch auf Unterseiten und Fehlerseiten gesendet.

Häufige Fragen

Verwandte Anleitungen

• Was ist SSL? Wozu dient SSL bei Websites und bei E-Mails?Was https und das Schloss-Symbol auf Websites und die SSL-Einstellung im E-Mail-Programm schützen und worin sie sich unterscheiden.
• XSS: Was ist das und wie verhindern Sie es?Kontextgerechtes Ausgabe-Escaping, Content-Security-Policy, HttpOnly-Cookie und die Bereinigung von Rich Text.
• Server- und Hosting-SicherheitSFTP/FTPS, Dateirechte, Verzeichnisauflistung, Fehleranzeige, sensible Dateien und Datenbankzugriff.
• Login- und SitzungssicherheitPasswort-Hashing, Begrenzung der Anmeldeversuche, Session-Fixation, Cookie-Flags und Berechtigungsprüfung bei jeder Anfrage.