Security Headers: Einführung und Architektur

Zuerst den Auslieferungsweg verstehen

Dieser Leitfaden richtet sich an Betreiber und Entwickler, die mehrere Schutzmechanismen zusammenführen. Er ergänzt die Einzelartikel und Stackanleitungen. Es gibt keine feste Anzahl von Headern, die jede Website auf jeder Antwort setzen müsste. Eine HTML-Seite, ein Stylesheet, eine JSON-Antwort und eine Weiterleitung brauchen unterschiedliche Betrachtungen.

Ermitteln Sie zunächst, welche Hosts und Routen öffentlich erreichbar sind, wo TLS endet und wer Antworten erzeugt. Nehmen Sie statische Seiten, serverseitig gerenderte Seiten, angemeldete Bereiche, Medien, Downloads und Fehlerantworten auf. Klären Sie, welche Einbettungen, externen Ressourcen, Popups, Loginanbieter und Bezahlwege benötigt werden. Eine Entscheidung wie „keine fremden Frames“ muss zu diesen Funktionen passen.

OWASP führt Security Misconfiguration in den Top 10:2025 als A02. Fehlende oder ungeeignete Sicherheitsheader sind dort ein möglicher Teilbefund neben vielen anderen Konfigurationsproblemen. Der Rang der Kategorie ist keine gemessene Priorität für einen bestimmten Header Ihrer Website. Dokumentieren Sie Schutzziel und Prüfung; eine Headerliste weist weder einen konkreten Exploit noch vollständige Compliance nach. OWASP A02:2025.

Vier mögliche Eingriffsebenen – mit Zuständigkeit je Regel

Die folgenden Ebenen beschreiben Funktionen. Ein Dienst kann mehrere davon vereinen; nicht jede Installation besteht aus vier getrennten Servern.

Legen Sie für jeden Header und jede Antwortfamilie eine verantwortliche Stelle fest. Eine Anwendung kann beispielsweise die dynamische CSP erstellen, während der TLS-Endpunkt HSTS setzt. Das ist eine bewusste Aufteilung. Dieselbe CSP unabhängig an mehreren Stellen zu pflegen, erzeugt dagegen schwer erkennbare Konflikte.

Ein einfacher Verantwortungsnachweis nennt Regel, Zweck, betroffene Hosts/Routen, erzeugende Schicht, nachgelagerte Änderungen, verantwortliche Person und Abnahmekriterium. Entscheidend ist nicht die Zahl der Konfigurationsdateien, sondern eine nachvollziehbare Entscheidung über die endgültige Antwort.

Quellen zu den beweglichen Plattformdetails: Next.js CSP, Next.js Proxy, Astro Middleware, Netlify Headergrenzen.

Für Hydrogen dokumentiert Shopify eine CSP-Erzeugung samt Nonce und deren Weitergabe an das gerenderte HTML. Eine Meta-CSP in einem Theme hat demgegenüber die Grenzen des Meta-Verfahrens, etwa für frame-ancestors und Report-Only. Cloudflare dokumentiert inzwischen einen O2O-Weg vor Shopify samt besonderen Voraussetzungen. Daraus folgt keine allgemeine Zusage, dass jede vorgeschaltete Headerregel unterstützt wird oder jeder Shopablauf unverändert funktioniert. Prüfen Sie vor einer solchen Architekturänderung die konkreten Anbieterbedingungen und Zertifikatserneuerung; übernehmen Sie keinen pauschalen Proxy-Tipp. Hydrogen CSP, Cloudflare für Shopify, CSP und Meta-Auslieferung.

Mehrfachwerte sind nicht einfach „letzter Header gewinnt“

HTTP kann mehrere Feldzeilen gleichen Namens übertragen. Wie daraus eine wirksame Regel entsteht, hängt vom jeweiligen Feld ab. Proxys und Bibliotheken können diese Zeilen zudem zusammenführen; eine übersichtliche Objektansicht ist deshalb nicht immer das ursprüngliche Format. RFC 9110 §§5.2–5.3.

Beispiel einer unbeabsichtigten Kombination:

Content-Security-Policy: script-src 'self'
Content-Security-Policy: script-src 'none'

Das zweite Feld erlaubt den eigenen Scripts keinen Ausweg. Es sperrt sie zusätzlich. Eine Änderung sollte daher eine vorhandene Policy gezielt ersetzen oder bewusst ergänzen, nicht auf eine vermutete Priorität hoffen. CSP3, mehrere Policies, HSTS §8.1, Referrer-Policy.

Bei nginx werden übergeordnete add_header-Direktiven im Standardmodell nur geerbt, wenn die aktuelle Ebene keine eigenen enthält. Schon ein zusätzliches add_header in einer location kann deshalb die geerbte Gruppe entfallen lassen. Seit 1.29.3 kann add_header_inherit das Modell ändern; merge hängt geerbte Werte an und kann bewusst oder unbewusst Duplikate erzeugen. always erweitert die Statuscodeabdeckung, repariert aber weder falsch gewählte Routen noch Header aus einer Schicht, die gar nicht durchlaufen wird. nginx Headers Module.

Bei Apache sind onsuccess und always unterschiedliche interne Headertabellen. always ist keine pauschale Obermenge aller vorhandenen Werte. Gerade CGI-/FastCGI- und Fehlerantworten können sonst doppelte Felder erzeugen. Prüfen Sie, aus welcher Tabelle der Ausgangswert stammt und welche davon die Regel verändert. Apache mod_headers.

Header, HTML und Cache müssen zusammenpassen

Ein CSP-Nonce erlaubt ausgewählte Scripts oder Styles über einen unvorhersehbaren Wert. Derselbe Wert muss im Header und am vorgesehenen Element stehen. Er muss für jede übertragene Policy neu erzeugt werden; ein fester Buildwert oder eine dauerhaft wiederverwendete Cache-Nonce ist kein geeigneter Ersatz. Für statische Inhalte können passende CSP-Hashes eine andere Strategie sein. CSP3, Nonce-Anforderungen, CSP-Grundlagen.

Ein typischer Fehler entsteht, wenn der Edge nur einen neuen Header erzeugt, aber altes HTML mit einer anderen Nonce aus dem Cache liefert. Der Browser blockiert dann die vorgesehenen Scripts. Werden Header und HTML gemeinsam aus einem Cache wiederverwendet, kann die Seite zwar funktionieren, die geforderte frische Nonce ist damit trotzdem nicht belegt. Die beiden Fragen „läuft die Anwendung?“ und „entspricht die Nonce-Erzeugung dem Schutzkonzept?“ brauchen getrennte Antworten.

Auch ein sichtbares Cache-Control: no-store beweist nicht, dass ein vorgeschalteter Dienst vorher nichts gespeichert hat. Cloudflare entscheidet über seinen Cache vor Response Header Transform Rules; eine dortige nachträgliche Änderung dieses Headers ändert die bereits getroffene Cloudflare-Cacheentscheidung nicht. Dafür sind die passenden Cache Rules beziehungsweise die Originvorgaben maßgeblich. Cloudflare Response Header Transform Rules.

Legen Sie deshalb fest, ob Header und Inhalt gemeinsam erzeugt, gespeichert, invalidiert und ausgeliefert werden. Persönliche Inhalte müssen bereits an der entscheidenden Cachegrenze richtig behandelt werden. HTTP-Cache, Service-Worker-Speicher und Back-Forward-Cache sind dabei verschiedene Systeme. Für vertrauliche Bereiche und Logout siehe Cache-Control und Clear-Site-Data.

Schrittweise einführen – nach dem tatsächlichen Risiko

Die folgenden drei Phasen sind eine Arbeitsfolge, keine feste Risikorangliste. Ein offen zwischengespeicherter persönlicher Bereich braucht sofort Aufmerksamkeit und wartet nicht auf eine spätere „Cachephase“.

1. Ausgangszustand und unmittelbare Fehler klären. HTTPS und Zertifikate, Antworttypen, MIME-Zuordnung, persönliche Inhalte und vorhandene Header erfassen. Benötigte Frames und Referrer-Übertragung bestimmen. Geeignete Regeln für nosniff, Frame-Einbettung, Referrer-Policy und HSTS mit ihrem jeweiligen Scope wählen. Den vorhandenen Browserdefault nicht als ausdrücklich gesetzte Betreiberpolicy ausgeben.
2. Anwendungspolicies erproben. CSP anhand der wirklich benötigten Quellen und Funktionen entwickeln; Report-Only kann Verstöße sichtbar machen. Permissions Policy begrenzt unterstützte Browserfunktionen, erteilt aber keine Nutzerfreigabe. SRI benötigt stabile Ressourcen, passende Metadaten und einen Erneuerungsprozess. Den Umgang mit Ausnahmen und Abhängigkeiten festlegen.
3. Besondere Anforderungen und Beobachtung ergänzen. COOP/COEP/CORP nur mit geklärtem Isolations- und Einbettungsbedarf einführen. Popup-Login, Zahlungen und fremde Ressourcen prüfen. Reporting mit Datenschutzkonzept, Empfänger und tatsächlichem Berichtsnachweis betreiben. Zusätzliche Header nach Reifegrad und Zielbrowsern bewerten, nicht allein wegen eines fehlenden Scannerpunkts aktivieren.

DNSSEC/CAA, Zertifikatsbetrieb und ein erreichbarer Sicherheitskontakt gehören zum Gesamtbetrieb, sind aber keine weiteren HTML-Header. Dafür führen DNS-Sicherheit, TLS und security.txt die Voraussetzungen aus.

HSTS braucht einen besonderen Rückweg. Steigern Sie die Laufzeit erst nach Prüfung der betroffenen HTTPS-Hosts; includeSubDomains erfasst auch tiefere und interne Subdomains. Ein bereits beim Browser gespeicherter Zeitraum endet nicht durch das bloße Entfernen der Konfiguration. max-age=0 kann die gespeicherte Regel bei einem erfolgreichen erneuten HTTPS-Kontakt löschen; übergeordnete oder vorgeladene Regeln bleiben gesondert zu betrachten. Die aktuell gelesene Preload-Seite empfiehlt HSTS, rät aber allgemein von Preloading ab und verlangt dafür eine bewusste Entscheidung. Eine Entfernung aus verbreiteten Browserlisten dauert. preload gehört deshalb nicht in ein allgemeines Startsnippet. RFC 6797, HSTS Preload: Einführung und Entfernung.

Kleine, zugeordnete Regeln statt einer universellen Gesamtdatei

Eine konsolidierte Konfiguration ist nützlich, wenn sie gemeinsam verwaltete Regeln zusammenfasst. Sie sollte weder dynamische Anwendungsregeln überschreiben noch alle Antworttypen gleich behandeln. Das folgende nginx-Fragment zeigt ausschließlich zwei statische Felder, keine vollständige Sicherheitskonfiguration:

# In den bewusst gewählten server-/location-Kontext einbinden.
# Vererbung und bereits vorhandene Felder vorher prüfen.
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;

Vorausgesetzt sind richtige MIME-Typen und die bewusste Wahl dieser Referrer-Policy für die betroffenen Antworten. Prüfen Sie die eingesetzte nginx-Version, den gesamten wirksamen Konfigurationsbaum und die tatsächlich ausgelieferten Felder. Das Fragment ist anhand der Direktiven-Dokumentation geprüft, hier aber nicht als nginx-Installation ausgeführt worden. Serverprüfung und kontrolliertes Laden der Konfiguration bleiben beim Betreiber.

Das entsprechende Prinzip bei Cloudflare wäre eine passende Response-Header-Regel mit Set für die ausgewählten Felder und begrenzten Matchbedingungen. Add kann weitere gleichnamige Felder anhängen. Regeln und ihren Ausführungspunkt prüfen, statt eine zweite unabhängige Policy über die Originantwort zu legen. Für Cache-Control gelten die zuvor beschriebenen Besonderheiten.

Eine vollständige Anwendungs-CSP, pauschales includeSubDomains; preload, COEP: credentialless, eine globale Clear-Site-Data-Anweisung oder ein fiktiver Reportempfänger werden durch diese beiden Felder nicht ersetzt. Sie benötigen jeweils eine eigene begründete Entscheidung. Bedingungen und konkrete Beispiele stehen in den Fachartikeln.

Abnahme im öffentlichen Antwortweg und im Browser

Eine Konfigurationsprüfung beantwortet, ob ein Dienst seine Regeln laden kann. Ein HTTP-Abruf zeigt, welche Antwort ausgeliefert wurde. Ein Browserlauf prüft, ob daraus die erwartete Wirkung entsteht und die Anwendung funktioniert. Diese Belege ergänzen einander.

Für die erste HTTP-Sicht auf eine eigene freigegebene Testdomain eignet sich ein GET-Abruf:

curl -sS -D - -o /dev/null 'https://www.example.com/'

Um eine begrenzte Redirectkette samt einzelnen Headerblöcken zu sehen:

curl -sS -L --max-redirs 5 -D - -o /dev/null 'https://www.example.com/'

Beispieldomain ersetzen und unerwartete Weiterleitungsziele vor weiteren Prüfungen klären. curl -I verwendet HEAD. HEAD sollte weitgehend dieselben Metadaten liefern, kann aber insbesondere bei dynamischer Erzeugung abweichen und prüft keinen ausgeführten Seiteninhalt. Die echte GET-Antwort und der genutzte Browserpfad sind deshalb entscheidend. TLS-Fehler durch deaktivierte Zertifikatsprüfung zu übergehen wäre keine erfolgreiche HTTPS-Abnahme. RFC 9110 §9.3.2.

Prüfen Sie die tatsächlich benötigten Browser und Geräte. Chromium deckt nicht automatisch Firefox oder Safari ab, und Playwright-WebKit ist kein Nachweis auf einem echten Safari-Gerät. Einige Regeln verändern gespeicherten Browserzustand; ein frisches Profil allein prüft daher nicht jede Bestandsnutzung. Nach erfolgreicher kleiner Einführung schrittweise ausweiten und Beschwerden, Fehler und Reports im vorgesehenen Betriebsrahmen beobachten. Fehlende Reports sind kein Fehlerfreiheitsnachweis.

In einer lokalen synthetischen Origin-/Proxy-Probe funktionierten passende Header-/HTML-Nonces. Ein neuer Header über altem HTML blockierte das Script; eine zusätzlich verschärfende CSP ebenfalls. Eine reine Report-Only-Policy blockierte es nicht. Wiederverwendete Cache-Nonces ließen das Script zwar laufen, erfüllten aber das Konzept einer frischen Nonce nicht. Diese Gegenfälle belegen Chromium-Verhalten im Modell, keine Abnahme eines realen CDN oder nginx-Servers.

Rückweg und laufende Verantwortung

Versionieren Sie die vorherige und die neue Konfiguration mit den betroffenen Routen und dem Zweck der Änderung. Definieren Sie vor der Umstellung, welche Funktionsfehler einen Rückweg auslösen und wer ihn ausführen kann. Eine enge Ausnahme für eine belegte Abhängigkeit ist besser nachvollziehbar als eine unbemerkte globale Lockerung.

Bei einem Fehler zunächst die verursachende Änderung an der zuständigen Schicht zurücknehmen, anschließend erforderliche Cacheinvalidierung und erneute Funktionsprüfung durchführen. Bereits geladene Dokumente, gespeichertes HSTS oder gelöschte Browserdaten lassen sich durch ein Server-Rollback nicht einfach rückwirkend verändern. Auch eine neue Report-Only-Policy hebt eine alte durchgesetzte CSP nicht auf. Für HSTS, Clear-Site-Data und gespeicherte Zustände gelten die jeweiligen Fachartikel.

Halten Sie Abhängigkeiten, Ausnahmen und Zuständigkeiten aktuell. Frameworkwechsel, CDN-Regeln, neue Drittanbieter oder geänderte Browserunterstützung können die Wirkung verändern. Ein einmaliger erfolgreicher Scan ist dafür kein dauerhafter Betriebsnachweis.

Was der Web Security Check dazu beitragen kann

Der Web Security Check liefert eine begrenzte externe Momentaufnahme. Die Hauptanalyse betrachtet die mit ihrem Prüfclient erreichbare Antwort und ihr HTML nach Weiterleitungen. Die erfasste Redirectkette und separate Nebenabrufe ergänzen diese Sicht. Der Prüfclient führt die Anwendung nicht wie ein angemeldeter Browser aus und besucht nicht automatisch alle Unterseiten.

Ein fehlender Header, ein Transportfehler und ein nicht untersuchter Zustand sind unterschiedliche Befunde. Ebenso beweist eine sichtbare Policy keine funktionierende Browserdurchsetzung, Cross-Origin-Isolation, erfolgreiche Berichtszustellung oder allgemeine Rechtskonformität. Verwenden Sie den Check für die passende externe Sicht und ergänzen Sie die Betreiber- und Browsernachweise für Ihr Schutzziel. CORS und die Sicherheit von API-Endpunkten behandelt der eigene API-Ratgeber.