Wer eine Website absichern möchte, sollte nicht nur an Passwörter, Updates und Firewalls denken. Auch HTTP-Sicherheits-Header spielen eine wichtige Rolle: Sie geben dem Browser Hinweise, wie Inhalte geladen werden dürfen, ob eine Verbindung ausschließlich verschlüsselt erfolgen soll und wie eine Seite mit eingebetteten Ressourcen umgeht. In diesem Ratgeber erfahren Sie, wie Sie die Sicherheits-Header einer Website prüfen, welche Header besonders relevant sind und wie Sie typische Fehlkonfigurationen einordnen.
Eine Prüfung der Header ist jedoch kein vollständiger Sicherheitsnachweis. Sie zeigt vor allem, welche Schutzmechanismen ein Server an den Browser kommuniziert. Anwendungsschwachstellen, unsichere Abhängigkeiten, fehlerhafte Berechtigungen oder Datenschutzprobleme werden dadurch nicht automatisch erkannt.
Was sind Sicherheits-Header?
Sicherheits-Header sind Bestandteile der HTTP-Antwort eines Webservers. Wenn ein Browser eine Website aufruft, sendet der Server neben dem eigentlichen HTML-Dokument verschiedene Metadaten zurück. Dazu gehören unter anderem Informationen zum Inhaltstyp, zur Zwischenspeicherung und zu Sicherheitsregeln.
Ein Header besteht meist aus einem Namen und einem Wert, zum Beispiel Strict-Transport-Security: max-age=31536000. Der Browser wertet diese Angaben aus und passt sein Verhalten daran an. Je nach Header kann er beispielsweise gemischte Inhalte blockieren, die Ausführung fremder Skripte einschränken oder verhindern, dass eine Website in einem fremden Frame eingebettet wird.
Wichtig ist die Unterscheidung zwischen Sicherheits-Headern und Sicherheitsfunktionen der Website selbst. Ein Header kann eine zusätzliche Schutzschicht bilden, ersetzt aber weder sichere Programmierung noch Zugriffskontrollen, regelmäßige Updates, Backups oder eine sorgfältige Konfiguration des Servers.
Warum sollte man Sicherheits-Header einer Website prüfen?
Achten Sie in der Darstellung auf die Hauptanfrage des Dokuments und die Antwort-Header. So lässt sich nachvollziehen, welche Sicherheitsregeln der Server tatsächlich an den Browser übermittelt.
Eine Header-Prüfung kann schnell Hinweise auf häufige Konfigurationsprobleme liefern. Fehlt beispielsweise ein geeigneter Schutz gegen Clickjacking, kann eine Website unter bestimmten Bedingungen in eine fremde Seite eingebettet werden. Ist die Content Security Policy zu offen formuliert, können ihre Schutzvorteile deutlich geringer ausfallen. Wird HTTPS nicht konsequent erzwungen, besteht außerdem das Risiko, dass Besucher über eine unverschlüsselte Variante auf die Website gelangen.
Die Prüfung ist besonders sinnvoll:
- vor dem Launch einer neuen Website oder eines Relaunches,
- nach Änderungen am Webserver, CDN, Proxy oder Caching-System,
- nach der Einführung eines neuen Analyse-, Werbe- oder Chat-Dienstes,
- bei der technischen Bestandsaufnahme einer älteren Website,
- als Bestandteil eines regelmäßigen Sicherheits- und Wartungsprozesses.
Eine auffällige oder fehlende Einstellung ist dabei nicht automatisch eine kritische Schwachstelle. Manche Header hängen von der Architektur, den eingebundenen Diensten und dem gewünschten Funktionsumfang ab. Eine gute Bewertung betrachtet deshalb immer den konkreten Anwendungsfall.
So prüfen Sie die Sicherheits-Header einer Website
Für eine erste Prüfung benötigen Sie in der Regel keinen besonderen Zugang zum Server. Die Header einer öffentlich erreichbaren Seite lassen sich mit den Entwicklerwerkzeugen des Browsers, mit Kommandozeilenwerkzeugen oder mit einem seriösen Online-Checker anzeigen. Online-Dienste können praktisch sein, sollten aber keine vertraulichen internen Adressen oder Zugangsdaten erhalten.
Prüfung mit den Entwicklerwerkzeugen
- Öffnen Sie die betreffende Website in einem modernen Browser.
- Rufen Sie die Entwicklerwerkzeuge auf und wechseln Sie zum Bereich Netzwerk oder Network.
- Laden Sie die Seite neu, damit die Netzwerkanfragen aufgezeichnet werden.
- Wählen Sie die Hauptanfrage des Dokuments aus, meist die Anfrage an die Startadresse.
- Öffnen Sie die Antwort-Header und suchen Sie nach sicherheitsrelevanten Einträgen.
- Prüfen Sie zusätzlich Weiterleitungen, Unterseiten und Seiten mit besonderen Funktionen.
Die Startseite allein reicht oft nicht aus. Ein Login, ein Kontaktbereich, eine Suchseite oder ein eingebetteter Dienst kann andere Header liefern als die öffentliche Startseite. Auch Fehlerseiten und Weiterleitungen sollten kontrolliert werden, weil sie gelegentlich über eine abweichende Serverkonfiguration ausgeliefert werden.
Prüfung mit einer Kommandozeile
Für eine schnelle Sichtprüfung kann ein HTTP-Client wie curl verwendet werden. Ein typischer Aufruf ist:
curl -I https://www.beispiel.de/Damit werden die Antwort-Header der angefragten URL angezeigt. Bei einer Weiterleitung kann zusätzlich die Option -L sinnvoll sein, um den gesamten Weiterleitungsverlauf zu betrachten:
curl -I -L https://www.beispiel.de/Die Ergebnisse sollten von einer fachkundigen Person interpretiert werden. Ein Kommandozeilenaufruf zeigt zwar den Serverantwortsatz, aber nicht automatisch, wie der Browser alle Ressourcen, Skripte und Richtlinien im konkreten Kontext verarbeitet.
Was bei der Prüfung dokumentiert werden sollte
Eine nachvollziehbare Prüfung sollte Datum, geprüfte URLs, verwendete Umgebung und die festgestellten Werte festhalten. Ergänzen Sie außerdem, ob die Website hinter einem Content Delivery Network, einem Reverse Proxy oder einem Hosting-System betrieben wird. Solche Komponenten können Header hinzufügen, verändern oder überschreiben.
Bewährt hat sich eine Tabelle mit den Spalten „Header“, „aktueller Wert“, „Ziel“, „Risiko“, „notwendige Änderung“ und „erneut geprüft am“. So bleiben Entscheidungen auch nach späteren Konfigurationsänderungen nachvollziehbar.
Die wichtigsten Sicherheits-Header im Überblick
Strict-Transport-Security
Strict-Transport-Security, kurz HSTS, weist den Browser an, eine Website für einen festgelegten Zeitraum nur über HTTPS aufzurufen. Dadurch können spätere Versuche, die Website über HTTP zu erreichen, automatisch auf HTTPS umgestellt werden.
Ein typischer Wert enthält max-age. Dieser legt fest, wie lange der Browser die Regel speichert. Die Direktive includeSubDomains bezieht auch Subdomains ein. Die Option preload sollte nicht leichtfertig verwendet werden, weil eine fehlerhafte Aufnahme in eine HSTS-Vormerkliste langfristige Auswirkungen auf die Erreichbarkeit haben kann.
Vor der Aktivierung sollte sichergestellt sein, dass alle relevanten Subdomains dauerhaft über gültiges HTTPS funktionieren. Besonders wichtig ist dies bei älteren Subdomains, Testsystemen und extern verwalteten Diensten.
Content-Security-Policy
Die Content-Security-Policy, kurz CSP, begrenzt, aus welchen Quellen eine Website Inhalte laden und welche Aktionen ein Browser ausführen darf. Sie kann unter anderem Skripte, Stylesheets, Bilder, Schriftarten, Frames und Verbindungen kontrollieren.
Eine CSP ist leistungsfähig, aber anspruchsvoll. Eine zu strenge Richtlinie kann legitime Funktionen blockieren. Eine zu großzügige Regel mit vielen allgemeinen Quellen, Inline-Skripten oder unsicheren Ausnahmen bietet dagegen möglicherweise nur begrenzten Schutz. Die Richtlinie sollte deshalb aus dem tatsächlichen Ressourcenmodell der Website abgeleitet werden.
Für die Einführung kann zunächst ein Berichtsmodus genutzt werden. Mit Content-Security-Policy-Report-Only werden Verstöße beobachtet, ohne die betroffenen Ressourcen sofort zu blockieren. Das erleichtert die Anpassung, ersetzt aber nicht die spätere Aktivierung einer durchsetzenden Richtlinie.
X-Content-Type-Options
Der Wert nosniff bei X-Content-Type-Options verhindert, dass der Browser den vom Server angegebenen Inhaltstyp eigenständig „errät“. Dadurch wird das Risiko reduziert, dass eine Datei anders interpretiert wird als vorgesehen.
Der Header funktioniert am besten, wenn der Server für jede Ressource einen korrekten Content-Type liefert. Eine falsche Typangabe sollte nicht durch andere Browserinterpretationen kaschiert werden, sondern in der Server- oder Anwendungslogik behoben werden.
Frame-Schutz mit CSP oder X-Frame-Options
Clickjacking bezeichnet den Versuch, eine Website in einem fremden Rahmen zu verbergen oder mit einer anderen Oberfläche zu überlagern. Schutz bieten die CSP-Direktive frame-ancestors und, für ältere Browserumgebungen, X-Frame-Options.
Mit frame-ancestors lässt sich genauer festlegen, welche Ursprünge eine Seite einbetten dürfen. X-Frame-Options: DENY verhindert grundsätzlich das Einbetten; SAMEORIGIN erlaubt es innerhalb desselben Ursprungs. Welche Einstellung geeignet ist, hängt davon ab, ob die Website legitime Einbettungen benötigt.
Referrer-Policy
Die Referrer-Policy steuert, welche Informationen beim Wechsel von einer Seite zu einer anderen als Referrer übermittelt werden. Eine restriktive Einstellung kann verhindern, dass vollständige URLs mit möglicherweise sensiblen Pfad- oder Abfrageparametern an fremde Websites gelangen.
Eine häufig verwendete, ausgewogene Richtung ist strict-origin-when-cross-origin. Sie übermittelt bei Wechseln zwischen verschiedenen Ursprüngen grundsätzlich weniger Details als bei Anfragen innerhalb derselben Website. Die konkrete Wahl sollte zum Analysekonzept, zu externen Diensten und zum Schutzbedarf der URLs passen.
Permissions-Policy
Mit Permissions-Policy kann eine Website den Zugriff auf bestimmte Browserfunktionen einschränken, beispielsweise Kamera, Mikrofon, Standort oder Vollbildmodus. Die Richtlinie ist besonders nützlich, wenn nur einzelne Komponenten eine solche Funktion benötigen.
Prüfen Sie, ob die erlaubten Ursprünge wirklich erforderlich sind. Eine möglichst kleine Berechtigungsliste reduziert die Auswirkungen, falls ein eingebetteter Dienst kompromittiert wird oder unerwartet auf eine Funktion zugreifen möchte.
Set-Cookie-Sicherheitsattribute
Cookies werden nicht ausschließlich über klassische Sicherheits-Header geschützt, sind bei einer Header-Prüfung aber unverzichtbar. Achten Sie insbesondere auf die Attribute Secure, HttpOnly und SameSite.
- Secure: Das Cookie wird nur über HTTPS übertragen.
- HttpOnly: JavaScript kann das Cookie nicht direkt auslesen.
- SameSite: Steuert, bei welchen seitenübergreifenden Anfragen ein Cookie mitgesendet wird.
Diese Attribute sollten für Sitzungs- und Authentifizierungscookies besonders sorgfältig geprüft werden. Sie verhindern nicht alle Angriffe, erschweren aber bestimmte Ausnutzungen und reduzieren die unbeabsichtigte Weitergabe von Sitzungsinformationen.
Header richtig bewerten: Nicht nur auf Vollständigkeit achten
Eine Checkliste mit vorhandenen Headern ist ein guter Anfang, aber keine ausreichende Qualitätsbewertung. Entscheidend ist, ob die Werte zur Website passen und tatsächlich durchgesetzt werden. Ein vorhandener Header kann wirkungslos oder problematisch sein, wenn seine Richtlinie zu weit gefasst ist, nur auf einer Unterseite gilt oder durch eine spätere Antwort überschrieben wird.
Kontext der Website berücksichtigen
Ein statischer Blog benötigt meist andere Regeln als ein Kundenportal mit Login, ein Onlineshop oder eine Webanwendung mit zahlreichen Drittanbietern. Für jede externe Quelle sollte geklärt werden, warum sie benötigt wird, welche Daten sie erhält und ob sie in der Sicherheitsrichtlinie enthalten sein muss.
Besondere Aufmerksamkeit verdienen Zahlungsseiten, Administrationsbereiche, Upload-Funktionen und Seiten mit personenbezogenen Informationen. Dort können zusätzliche Anforderungen an Cookies, Caching, Zugriffssteuerung und Protokollierung gelten.
Direkte Antworten und Weiterleitungen unterscheiden
Bei einer HTTPS-Website beginnt der Aufruf manchmal mit einer HTTP-Adresse und wird anschließend weitergeleitet. Prüfen Sie, ob sowohl die Weiterleitungsantwort als auch die endgültige HTTPS-Antwort sinnvoll konfiguriert sind. HSTS wird nur über eine sichere Verbindung zuverlässig gesetzt; eine rein unverschlüsselte Ausgangsantwort kann deshalb nicht als vollständige Absicherung gelten.
Browser-Konsole und Netzwerkanfragen einbeziehen
Eine Header-Prüfung sollte mit der Browser-Konsole ergänzt werden. Dort können CSP-Verstöße, blockierte Ressourcen, Mixed Content und Cookie-Probleme sichtbar werden. Öffnen Sie außerdem die Liste der geladenen Ressourcen und prüfen Sie, ob externe Skripte oder Verbindungen auftauchen, die in der dokumentierten Sicherheitsrichtlinie nicht vorgesehen sind.
Typische Fehler bei Sicherheits-Headern
- Nur die Startseite wird geprüft: Login-, Fehler- und Funktionsseiten können andere Antworten liefern.
- Alle Quellen werden pauschal erlaubt: Sehr offene CSP-Regeln verlieren einen großen Teil ihrer Schutzwirkung.
- Unsichere Ausnahmen bleiben dauerhaft aktiv: Inline-Skripte oder dynamische Codeausführung sollten nur nach sorgfältiger Prüfung erlaubt werden.
- HSTS wird zu früh aktiviert: Nicht erreichbare Subdomains können danach Probleme verursachen.
- Cookies werden übersehen: Sicherheitsattribute sind für Sitzungen genauso wichtig wie viele klassische Header.
- Ein Online-Score wird als Audit verstanden: Automatische Bewertungen erkennen nicht alle Architektur- und Geschäftsrisiken.
- Änderungen werden nicht nachgetestet: Ein neues Plugin, ein CDN oder ein Proxy kann Header unbemerkt verändern.
Ein praktischer Prüfprozess für Teams
Ein wiederholbarer Prozess hilft mehr als eine einmalige Momentaufnahme. Legen Sie zunächst die wichtigsten URL-Typen fest: Startseite, Login, geschützte Bereiche, Formularseiten, Medien- oder Downloadseiten, Fehlerseiten und gegebenenfalls API-Endpunkte.
Erfassen Sie danach die aktuellen Headerwerte in einer übersichtlichen Dokumentation. Bewerten Sie jeden Befund nach Auswirkung, Eintrittswahrscheinlichkeit und betroffener Funktion. Nicht jeder fehlende Header hat dieselbe Priorität. Ein fehlender Schutz auf einer öffentlich eingebetteten Seite kann anders zu beurteilen sein als eine fehlende Einschränkung in einem internen Administrationsbereich.
Ändern Sie Richtlinien schrittweise und testen Sie anschließend mindestens folgende Szenarien:
- normaler Seitenaufruf und Navigation,
- Anmeldung, Abmeldung und Sitzungsablauf,
- Formulare und Datei-Uploads,
- eingebundene Analyse-, Zahlungs- oder Supportdienste,
- mobile Darstellung und alternative Browser,
- Weiterleitungen, Fehlerseiten und nicht angemeldete Zugriffe.
Bei einer Content Security Policy ist ein Bericht über blockierte oder unerlaubte Ressourcen besonders hilfreich. Prüfen Sie allerdings, ob solche Berichte personenbezogene oder sensible URL-Daten enthalten können. Protokollierung sollte zweckgebunden, zugriffsgeschützt und passend zu den geltenden Datenschutzanforderungen umgesetzt werden.
Was eine Header-Prüfung nicht abdeckt
Sicherheits-Header schützen vor allem die Kommunikation zwischen Server und Browser. Sie erkennen keine SQL-Injection, keine fehlerhafte Zugriffskontrolle und keine unsichere Passwortspeicherung. Auch veraltete Komponenten, schädliche Uploads, Serverfehlkonfigurationen oder kompromittierte Drittanbieter werden durch eine Header-Prüfung nicht zuverlässig entdeckt.
Für eine umfassendere Bewertung können je nach Schutzbedarf weitere Maßnahmen erforderlich sein: sichere Entwicklungsprozesse, Code-Reviews, Abhängigkeitsprüfungen, Schwachstellenscans, Berechtigungstests, Protokollanalysen und eine nachvollziehbare Update-Strategie. Umfang und Tiefe sollten sich am Risiko, an der Datenverarbeitung und an der technischen Komplexität orientieren.
FAQ
Welche Sicherheits-Header sind für eine Website besonders wichtig?
Das hängt von der Website ab. Häufig gehören HSTS, Content Security Policy, X-Content-Type-Options, Referrer-Policy und ein Schutz gegen unerwünschtes Framing zu den zentralen Themen. Für Websites mit Login sollten zusätzlich die Cookie-Attribute und die Sitzungsverwaltung geprüft werden.
Kann ich Sicherheits-Header selbst prüfen?
Eine grundlegende Prüfung ist mit den Browser-Entwicklerwerkzeugen oder einem Kommandozeilenwerkzeug möglich. Für die richtige Bewertung komplexer CSP-Regeln, Authentifizierungsbereiche und Drittanbieterintegrationen kann jedoch technisches Fachwissen erforderlich sein.
Ist ein fehlender Header automatisch eine Sicherheitslücke?
Nein. Ein fehlender Header ist zunächst ein Prüfhinweis. Ob daraus ein relevantes Risiko entsteht, hängt von den Inhalten, den Nutzerflüssen, der Serverarchitektur und den vorhandenen Ersatzmaßnahmen ab. Eine pauschale Bewertung ohne Kontext ist daher nicht zuverlässig.
Warum funktioniert eine Website nach einer CSP-Änderung nicht mehr?
Eine CSP kann Ressourcen blockieren, die in der Richtlinie nicht vorgesehen sind. Häufig betroffen sind externe Skripte, Schriftarten, Bilder, API-Verbindungen oder eingebettete Rahmen. Nutzen Sie zunächst den Berichtsmodus und prüfen Sie die Browser-Konsole, bevor Sie einzelne Quellen gezielt freigeben.
Wie oft sollten Sicherheits-Header geprüft werden?
Eine feste Häufigkeit gibt es nicht für jede Website. Sinnvoll ist eine Prüfung vor dem Launch, nach Infrastruktur- oder Pluginänderungen und regelmäßig im Rahmen der Wartung. Besonders dynamische Websites sollten ihre Header nach Änderungen an Drittanbietern oder Sicherheitsrichtlinien erneut kontrollieren.
Was muss bei HSTS besonders beachtet werden?
Vor der Aktivierung müssen die relevanten Domains und Subdomains zuverlässig über gültiges HTTPS erreichbar sein. Testen Sie zuerst die HTTPS-Funktion und setzen Sie die Gültigkeitsdauer vorsichtig. Erweiterungen wie includeSubDomains und preload sollten erst nach einer gründlichen Prüfung eingesetzt werden.
Reicht ein guter Wert in einem Online-Header-Checker aus?
Nein. Ein Checker kann fehlende oder ungewöhnliche Header schnell sichtbar machen, ersetzt aber keine Prüfung der Website-Funktion, der Anwendungssicherheit und der eingebundenen Dienste. Verwenden Sie solche Ergebnisse als Ausgangspunkt für eine technische Bewertung, nicht als vollständiges Sicherheitszertifikat.
Fazit: Sicherheits-Header systematisch prüfen
Wer die Sicherheits-Header einer Website prüft, erhält einen wichtigen Einblick in die Kommunikation zwischen Webserver und Browser. Besonders relevant sind HTTPS-Erzwingung, Inhaltsrichtlinien, Schutz vor unerwünschten Einbettungen, korrekte Inhaltstypen, Referrer-Steuerung, Browserberechtigungen und sichere Cookies.
Am zuverlässigsten ist ein strukturierter Prozess: mehrere URL-Typen untersuchen, Headerwerte dokumentieren, Browsermeldungen auswerten, Änderungen schrittweise umsetzen und die wichtigsten Nutzerflüsse erneut testen. So wird aus einer einfachen Checkliste eine belastbare technische Kontrolle. Gleichzeitig bleibt wichtig: Sicherheits-Header sind eine Schutzschicht unter mehreren und können eine umfassende Sicherheitsprüfung der Website nicht ersetzen.