Security-Header und HTTPS: was dein Server dem Browser mitgibt

Security-Header sind Anweisungen, die dein Server bei jeder Antwort an den Browser mitschickt und die dort Schutzmaßnahmen einschalten: nur verschlüsselt verbinden, keine fremden Skripte ausführen, die Seite nicht in fremde Rahmen einbetten lassen. Schickt der Server einen Header nicht, gilt das Standardverhalten des Browsers — und das ist in den meisten Fällen das erlaubende. Deshalb fehlen diese Header auf so vielen Websites: Niemand hat sie abgeschaltet, es hat sie nur nie jemand eingeschaltet. Die Grundlage für alles ist HTTPS; ohne verschlüsselte Verbindung wirken die meisten Header gar nicht.

Was diese Header leisten und was nicht

Security-Header schränken ein, was der Browser deiner Besucher auf deiner Seite zulässt. Ein Beispiel: Ohne entsprechende Anweisung darf jede fremde Website deine Seite in einem Rahmen einbetten. Ein Angreifer kann deine echte Seite dann unsichtbar über seine eigene legen und Besucher auf Schaltflächen klicken lassen, die sie nicht sehen — das nennt sich Clickjacking. Mit dem passenden Header verweigert der Browser das Einbetten.

Das OWASP Secure Headers Project, eine Sammlung von Empfehlungen der Open Worldwide Application Security Project Foundation, beschreibt den Zweck so: Header, die moderne Browser davon abhalten, in leicht vermeidbare Schwachstellen zu laufen.

Wichtig für die Einordnung: Die Header ersetzen keine sichere Software. Sie sind eine zweite Verteidigungslinie, die greift, wenn an anderer Stelle etwas schiefgegangen ist. Sie verändern das Aussehen nicht und sind Serverkonfiguration, keine Entwicklung.

HTTPS ist die Grundlage

Was ein Zertifikat leistet: Die Verbindung zwischen Besucher und Server ist verschlüsselt und gegen Veränderung unterwegs geschützt. web.dev nennt beides: HTTPS verhindert, dass Dritte die Kommunikation manipulieren, etwa Werbung einschleusen, und dass unverschlüsselte Abrufe Rückschlüsse auf Verhalten und Identität deiner Besucher erlauben — auch auf Seiten ohne sensible Daten. Viele neuere Browserfunktionen setzen HTTPS ohnehin voraus.

Was es nicht leistet: Es sagt nichts über die Seriosität des Betreibers. Google hat das Schloss in Chrome deshalb mit Version 117 im September 2023 durch ein neutrales Einstellungssymbol ersetzt. Die Begründung des Chrome-Teams: In einer Studie von 2021 verstanden nur 11 Prozent der Teilnehmer, was das Schloss genau bedeutet, und fast alle Phishing-Seiten nutzen selbst HTTPS.

Für Google zählt HTTPS mit: Seit 2014 ist es ein Rankingsignal, damals ausdrücklich ein leichtgewichtiges. In Googles heutigen Hinweisen zur Nutzererfahrung steht es als Prüffrage: Werden deine Seiten sicher ausgeliefert?

Zertifikate kosten heute nichts. Let's Encrypt stellt sie kostenlos aus, derzeit mit 90 Tagen Laufzeit. Die Laufzeit sinkt: auf 64 Tage ab Februar 2027 und auf 45 Tage ab Februar 2028, weil die Regeln der Branche es so vorsehen. Ohne funktionierende automatische Erneuerung geht das nicht mehr.

Drei Dinge gehören geprüft:

• Läuft die Erneuerung? Automatik kann still fehlschlagen. Ein abgelaufenes Zertifikat erzeugt eine ganzseitige Warnung im Browser.
• Deckt das Zertifikat alle Adressvarianten ab? Mit und ohne www. und jede genutzte Subdomain.
• Wird die unverschlüsselte Fassung dauerhaft weitergeleitet? Google empfiehlt für einen Umzug dauerhafte serverseitige Weiterleitungen mit 301 oder 308 — und keine langen Ketten.

Gemischte Inhalte

Gemischte Inhalte sind eine verschlüsselt ausgelieferte Seite, die einzelne Dateien unverschlüsselt nachlädt.

Was zählt: alles, was der Browser lädt — Skripte, Stylesheets, Bilder, Schriften, Rahmen, Medien. Was nicht zählt: ein Link auf eine unverschlüsselte Seite. Das ist Navigation, kein Laden, und wird von manchen Prüfwerkzeugen fälschlich als Fehler gemeldet.

Was passiert: Laut MDN stellen Browser Bilder, Audio und Video automatisch auf HTTPS um. Alles andere — Skripte, Stylesheets, Rahmen, Schriften, Datenabrufe — wird blockiert. Die Seite sieht dann kaputt aus oder funktioniert nicht mehr richtig. Und ein Bild, dessen Server kein HTTPS kann, fehlt trotz Umstellung.

Die häufigste Ursache ist ein Umzug von HTTP auf HTTPS, bei dem alte Adressen in der Datenbank stehen geblieben sind — in Beiträgen, Widgets und Theme-Einstellungen. Die Behebung ist ein Suchen und Ersetzen in der Datenbank: http://deinedomain.de durch https://deinedomain.de. Vorher eine Sicherung ziehen.

Die Header im Einzelnen

HSTS — nur noch verschlüsselt

Was er sagt: Dieser Host ist ausschließlich über HTTPS zu erreichen, für die angegebene Dauer in Sekunden. Nach MDN lässt der Browser Besucher dann auch nicht mehr an Zertifikatsfehlern vorbeiklicken.

Der Nutzen: Wer die Adresse ohne Protokoll eintippt, baut sonst zuerst eine unverschlüsselte Verbindung auf und wird erst dann weitergeleitet. Dieser erste Abruf ist angreifbar. Mit HSTS fällt er ab dem zweiten Besuch weg.

• Die Dauer: max-age. Für die Vorabliste der Browser ist mindestens ein Jahr (31536000) Pflicht, OWASP empfiehlt zwei Jahre (63072000).
• Die Reichweite: Ohne includeSubDomains gilt die Regel nur für den Host, der sie schickt. Die Hauptdomain sieht geschützt aus, Subdomains bleiben unverschlüsselt erreichbar.

Die Voraussetzung ist ernst zu nehmen. Browser ignorieren den Header, wenn er über unverschlüsseltes HTTP kommt. Das Risiko liegt woanders: Mit includeSubDomains gilt die Regel auch für eine Testumgebung oder ein altes Werkzeug auf einer Subdomain. Hat die kein gültiges Zertifikat, ist sie für jeden Besucher gesperrt, der die Hauptdomain vorher besucht hat. Also erst alle Subdomains prüfen.

Die Vorabliste ist eine Entscheidung, keine Einstellung. Mit preload beantragst du die Aufnahme in eine Liste, die Browser schon vor dem ersten Besuch kennen. hstspreload.org warnt, dass eine Aufnahme sich nicht leicht rückgängig machen lässt und eine Entfernung Monate braucht, bis sie bei den Nutzern ankommt. Darauf zu verzichten ist eine bewusste Haltung, kein Versäumnis.

CSP — welche Quellen laden dürfen

Was er sagt: Von welchen Adressen jede Art von Ressource geladen werden darf und ob Code direkt in der Seite laufen darf. MDN nennt als Hauptzweck den Schutz vor eingeschleustem Code (Cross-Site-Scripting) und vor Clickjacking.

Das ist der wirkungsvollste und der aufwendigste Header. Richtig eingestellt verhindert er, dass eingeschleuster Code ausgeführt wird. Falsch eingestellt legt er Teile der Website lahm.

Zwei Angaben schwächen ihn stark: unsafe-inline erlaubt Code direkt in der Seite, unsafe-eval dynamisch erzeugten Code. MDN schreibt, dass unsafe-inline einen großen Teil des Zwecks einer CSP aufhebt, und empfiehlt stattdessen Nonces oder Hashes. Viele verbreitete WordPress-Themes und -Plugins kommen trotzdem nicht ohne unsafe-inline aus — dann ist eine CSP mit dieser Lücke immer noch besser als keine.

Der vernünftige Weg zur Einführung ist gestuft:

1. Zuerst Content-Security-Policy-Report-Only setzen. Dieser Header meldet Verstöße, blockiert aber nichts. Am besten auf einer Testumgebung.
2. Die Meldungen auswerten, bis nur noch erwartete Ressourcen auftauchen. Meldungen, die von Browser-Erweiterungen der Besucher stammen, herausfiltern — sonst suchst du Fehler, die es auf deiner Seite nicht gibt.
3. Dann auf den scharfen Header umstellen.

X-Content-Type-Options — kein Raten von Dateitypen

Was er sagt: nosniff — der Browser hält sich an den angegebenen Dateityp, statt ihn aus dem Inhalt zu erraten. Skripte und Stylesheets mit falschem Typ werden blockiert. Ein Wert, praktisch kein Nebenwirkungsrisiko, der einfachste Punkt auf dieser Liste.

Schutz gegen Einbetten

Es gibt den älteren Header X-Frame-Options mit DENY oder SAMEORIGIN und die Angabe frame-ancestors in der CSP. OWASP schreibt, dass frame-ancestors den älteren Header in Browsern, die ihn unterstützen, ablöst; X-Frame-Options bleibt für ältere Browser sinnvoll. frame-ancestors kann einzelne erlaubte Adressen nennen und funktioniert nur als Header, nicht als meta-Tag.

Referrer-Policy

Was er sagt: Wie viel von der aktuellen Adresse mitgeschickt wird, wenn jemand einen externen Link klickt oder die Seite etwas Externes lädt. Das zählt, wenn deine Adressen sprechend sind, etwa Kennungen oder Suchbegriffe enthalten.

Der empfohlene Wert strict-origin-when-cross-origin schickt innerhalb deiner Seite die volle Adresse, an fremde Ziele nur die Domain und an unverschlüsselte Ziele gar nichts. Laut MDN ist genau das seit 2020 das Standardverhalten, wenn kein Header gesetzt ist. Der Header hält die Absicht trotzdem fest und gilt auch dort, wo ein Browser anders voreingestellt ist.

Permissions-Policy

Was er sagt: Welche Browserfunktionen die Seite und eingebettete Rahmen nutzen dürfen — Kamera, Mikrofon, Standort und weitere. Die praktische Form ist eine leere Erlaubnisliste: camera=(), microphone=(), geolocation=(). Damit sind diese Funktionen für die Seite und jeden Rahmen darin gesperrt, etwa für eine eingebettete Karte. MDN weist darauf hin, dass der Header noch nicht in allen verbreiteten Browsern funktioniert — er schadet dort nicht, wirkt aber auch nicht.

Header, deren richtiger Zustand die Abwesenheit ist

Es gibt Header, deren Vorhandensein der Mangel ist. Ein Prüfbericht, der ihr Fehlen bemängelt, ist veraltet.

Header	Status	Was zu tun ist
X-XSS-Protection	veraltet; kann laut MDN in sonst sicheren Seiten selbst Lücken erzeugen	weglassen oder auf 0 setzen, CSP nutzen
Expect-CT	veraltet; Chromium setzt Zertifikatstransparenz seit Version 107 ohnehin durch	entfernen
Public-Key-Pins	2018 aus Chromium entfernt, von keinem aktuellen Browser unterstützt	entfernen

Die Falle bei doppelter Konfiguration

Ein Header kann an zwei Stellen gesetzt werden: im Webserver und in der Anwendung, etwa in WordPress oder einem Plugin. Setzen beide denselben Header, fasst der Empfänger die Werte nach dem HTTP-Standard zu einem Feld mit Komma zusammen — zum Beispiel nosniff, nosniff.

Für Prüfwerkzeuge ist das eine Falle: Wer den Wert exakt mit dem erwarteten vergleicht, meldet einen eigentlich konfigurierten Host als fehlerhaft. Und bei widersprüchlichen Werten weiß niemand mehr sicher, welcher gilt. Setz jeden Header an genau einer Stelle — dann muss die nächste Änderung auch nur an einer gemacht werden.

Was der Server sonst noch verrät

• Versionsangaben in Headern. Server und X-Powered-By nennen oft Software und Version. OWASP empfiehlt, X-Powered-By zu entfernen und Server zu entfernen oder nichtssagend zu machen.
• Fehlermeldungen im Seiteninhalt. Ein ausgegebener PHP-Fehler zeigt Dateipfade und Versionen. WordPress rät selbst davon ab, die Debug-Werkzeuge auf Live-Seiten zu nutzen. Wenn du Fehler brauchst: WP_DEBUG_LOG an, WP_DEBUG_DISPLAY aus — der Fehler landet im Protokoll statt auf der Seite.

Wie du das selbst prüfst

• Online-Prüfdienst für Security-Header: Adresse eintragen, Liste der gesetzten und fehlenden Header lesen. Die Note ist nicht das Ziel, die Liste darunter ist der nützliche Teil — und die veralteten Header aus der Tabelle oben gehören nicht auf die Fehlliste.
• Von Hand: Entwicklerwerkzeuge (F12), Reiter Netzwerk, Seite neu laden, erste Zeile anklicken, Antwort-Header lesen.
• Zertifikat: Symbol links in der Adresszeile anklicken. Aussteller, Ablaufdatum und abgedeckte Adressen stehen dort.
• Gemischte Inhalte: Entwicklerwerkzeuge, Reiter Konsole, Seite neu laden. Blockierte Ressourcen stehen dort im Klartext.
• Die einfachste Prüfung: deine Seite mit http:// aufrufen. Du musst über eine dauerhafte Weiterleitung bei https:// landen.

Was zu tun ist

Nach Aufwand und Risiko geordnet:

1. Zertifikat, Erneuerung und dauerhafte Weiterleitung prüfen. Voraussetzung für alles Weitere.
2. Gemischte Inhalte beseitigen. Sichtbar für jeden Besucher.
3. Die einfachen Header setzen: X-Content-Type-Options, X-Frame-Options, Referrer-Policy, Permissions-Policy. Wenige Zeilen, kaum Risiko für die Funktion.
4. Veraltete Header entfernen und Versionsangaben sowie Fehlerausgabe abschalten.
5. HSTS setzen — includeSubDomains erst, wenn jede Subdomain ein gültiges Zertifikat hat. Über preload bewusst entscheiden.
6. CSP zuletzt, gestuft über den Meldemodus, auf einer Testumgebung beginnend. Der einzige Punkt, der ernsthaft Zeit kostet — und der einzige, der die Website lahmlegen kann.

Nach jeder Änderung prüfen: Startseite, eine Unterseite, ein Formular, ein eingebettetes Video. Header wirken sofort und auf allen Seiten.

Und eine Einordnung zum Stellenwert: Patchstack zählte für 2025 bei WordPress 91 Prozent der neuen Schwachstellen in Plugins. In zwei Tests hielten die üblichen Schutzschichten der Hoster nur 12 beziehungsweise 26 Prozent der Angriffe auf, und bei den meistangegriffenen Lücken lag der Median bis zum ersten Angriff bei fünf Stunden. Security-Header sind deshalb kein Ersatz für Aktualisierungen, wenige Plugins und gute Zugangsdaten. Sie sind billig, sie helfen — und sie sind die zweite Reihe, nicht die erste.

Quellen

• MDN, Strict-Transport-Security — Wirkung, includeSubDomains, Vorgaben für preload, Header über HTTP wird ignoriert, erster Besuch ungeschützt: developer.mozilla.org
• hstspreload.org — Voraussetzungen der Vorabliste, Entfernung dauert Monate: hstspreload.org
• MDN, Content Security Policy — Schutz vor XSS und Clickjacking, unsafe-inline und unsafe-eval, Nonces und Hashes: developer.mozilla.org
• MDN, Content-Security-Policy-Report-Only — melden ohne zu blockieren: developer.mozilla.org
• MDN, X-Content-Type-Options — nosniff, blockierte Skripte und Stylesheets: developer.mozilla.org
• MDN, X-Frame-Options — Werte und Verweis auf frame-ancestors: developer.mozilla.org
• MDN, CSP frame-ancestors — nicht als meta-Tag nutzbar: developer.mozilla.org
• MDN, Referrer-Policy — strict-origin-when-cross-origin als Standard seit 2020: developer.mozilla.org
• MDN, Permissions-Policy — leere Erlaubnisliste, Wirkung auf Rahmen, eingeschränkte Unterstützung: developer.mozilla.org
• MDN, X-XSS-Protection — veraltet, kann Lücken erzeugen: developer.mozilla.org
• MDN, Expect-CT — veraltet seit Chromium 107: developer.mozilla.org
• MDN, Mixed content — Umstellung von Bildern und Medien, Blockieren aller anderen Ressourcen: developer.mozilla.org
• OWASP, Secure Headers Project — Zweck des Projekts: owasp.org
• OWASP, HTTP Headers Cheat Sheet — empfohlene Werte, HSTS mit zwei Jahren, frame-ancestors löst X-Frame-Options ab, Public-Key-Pins, Server und X-Powered-By: cheatsheetseries.owasp.org
• IETF, RFC 9110 HTTP Semantics, Abschnitt 5.3 — Zusammenführen wiederholter Felder mit Komma: rfc-editor.org
• web.dev, Why HTTPS matters — Schutz vor Manipulation, auch für Seiten ohne sensible Daten: web.dev
• Chromium Blog, An Update on the Lock Icon — Chrome 117, 11 Prozent der Studienteilnehmer: blog.chromium.org
• Google Search Central Blog, HTTPS as a ranking signal — leichtgewichtiges Signal seit 2014: developers.google.com
• Google Search Central, Understanding page experience — sichere Auslieferung als Prüffrage: developers.google.com
• Google Search Central, Site moves with URL changes — dauerhafte Weiterleitungen mit 301 oder 308: developers.google.com
• Let's Encrypt, FAQ — kostenlose Zertifikate, 90 Tage Laufzeit: letsencrypt.org
• Let's Encrypt, Decreasing Certificate Lifetimes to 45 Days — Zeitplan 2027 und 2028: letsencrypt.org
• WordPress Developer Resources, Debugging in WordPress — keine Debug-Werkzeuge auf Live-Seiten, Protokoll statt Anzeige: developer.wordpress.org
• Patchstack, State of WordPress Security in 2026 — 91 Prozent in Plugins, 12 und 26 Prozent blockiert, fünf Stunden Median: patchstack.com