Erst die Pflicht bestimmen, dann die passende Maßnahme
Quellenstand: 27. September 2026. Die hier betrachteten Regelwerke haben unterschiedliche Adressaten: NIS2 betrifft gesetzlich erfasste Einrichtungen, die DSGVO die Verarbeitung personenbezogener Daten in ihrem Anwendungsbereich, der Cyber Resilience Act bestimmte Produkte und DORA den Finanzsektor. IT-Grundschutz und PCI DSS sind davon getrennt als Standards beziehungsweise konkrete Prüfrahmen zu betrachten.
Stellen Sie für jede Webanwendung drei Fragen: Welche Daten und Dienste schützt sie? Welche Vorschriften und vertraglichen Anforderungen gelten tatsächlich? Welche Maßnahmen und Prüfungen belegen die erforderliche Wirkung? Ein passender Header kann Teil der Antwort sein. Er ersetzt weder sichere Anwendungslogik noch Berechtigungen, Wartung und Vorfallbearbeitung.
Ein typischer Grenzfall: Eine Website liefert eine strenge Content Security Policy. Die Anwendung gibt angemeldeten Kunden trotzdem fremde Rechnungen aus. Der Header löst dieses Berechtigungsproblem nicht. Umgekehrt beweist ein fehlender optionaler Header ohne Betrachtung von Funktion, Browserregeln und Risiko noch keinen Gesetzesverstoß.
Technische Maßnahmen und ihre Nachweisgrenzen
Die Tabelle ordnet alle technischen Themen dieser Übersicht ein. Sie ist kein vollständiges Mapping auf eine Rechtsnorm. Die zusätzliche Prüfung muss den betroffenen Ablauf abdecken, beispielsweise eine Anmeldung, den Checkout oder eine administrative Funktion; eine Startseitenantwort allein genügt dafür häufig nicht.
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Mechanismus | Möglicher technischer Beitrag | Was zusätzlich geprüft werden muss |
|---|---|---|
| Content Security Policy | Geeignete durchgesetzte Direktiven beschränken Ressourcen und Scriptausführung. | Effektive Regeln, Quellen, Nonces oder Hashes und die Wirkung im Browser. Report-Only blockiert nicht; eine CSP ersetzt weder Fehlerbehebung noch vollständige Scriptverwaltung. |
| HSTS | Ein Browser verwendet für einen ihm als HSTS-Host bekannten Namen HTTPS. | Erstkontakt, Gültigkeitsdauer, Subdomains und gegebenenfalls tatsächliche Preload-Aufnahme. HSTS verschlüsselt selbst keine Daten und bewertet nicht die gesamte TLS-Konfiguration. |
| Cookie-Sicherheit | Attribute begrenzen je nach Attribut Übertragung, Scriptzugriff und bestimmte Cross-Site-Verwendungen. | Alle relevanten Cookies über Login-, Rollen- und Kaufabläufe, serverseitige Sitzungsregeln und CSRF-Schutz. Ein sicher konfiguriertes Cookie beweist keine Einwilligung oder andere Rechtsgrundlage. |
| X-Frame-Options | Unterstützt Beschränkungen der Einbettung in Frames. | Effektive Einbettung einschließlich CSP frame-ancestors, benötigte Integrationen und Zielbrowser. Ein vorhandener Header ist keine allgemeine Clickjacking- oder Anwendungssicherheitsgarantie. |
| Referrer-Policy | Begrenzt, welche Referrer-Informationen der Browser bei Anfragen mitsendet. | Policy, Navigations- und Ressourcenkontext. Sie entfernt keine personenbezogenen Daten aus URLs, Serverlogs oder anderen Übermittlungen. |
| X-Content-Type-Options | nosniff bindet insbesondere Script- und Stylesheet-Nutzung an passende MIME-Typen. | Tatsächlicher Inhaltstyp und Nutzungskontext. Kein universeller Schutz sämtlicher Inhalte oder aller JSON-Antworten. |
| Permissions-Policy | Steuert unterstützte Browserfunktionen für Dokumente und Einbettungen. | Featuredefaults, Browserunterstützung, eingebettete Dokumente und gegebenenfalls zusätzliche Nutzerfreigaben. Ein fehlender Header bedeutet nicht, dass jede Funktion frei zugänglich ist. |
| CORP, COOP und COEP | Steuern bestimmte Ressourcennutzungen und Beziehungen zwischen Browserdokumenten. | Zusammenwirken der Policies, sichere Umgebung, Einbettung und tatsächlicher Browserzustand. Einzelne Header beweisen keine vollständige Cross-Origin-Isolation und keinen umfassenden Schutz vor Seitenkanälen. |
| Subresource Integrity | Ermöglicht Integritätsprüfung geeigneter eingebundener Ressourcen gegen erwartete Hashwerte. | Tatsächliche Ressource, Hashübereinstimmung, Cross-Origin-Voraussetzungen und Änderungsverfahren. Ein Attributfund ist noch keine durchgeführte Hashvalidierung und kein vollständiges Scriptinventar. |
| NEL und Reporting | Unterstützende Browser können bestimmte Fehler und Verstöße an konfigurierte Empfänger melden. | Browserunterstützung, tatsächlich eingehende Meldungen, Auswertung, Datenschutz und Abdeckung. Ein Endpunkt belegt keine vollständige Angriffs- oder Manipulationserkennung. |
| security.txt | Veröffentlicht Kontaktinformationen für Schwachstellenmeldungen. | Erreichbarkeit, Zuständigkeit und Bearbeitung. Die Datei ersetzt keine gesetzliche Meldung eines erheblichen Vorfalls an eine Behörde. |
| DNSSEC und CAA | DNSSEC ermöglicht Herkunfts- und Integritätsprüfung von DNS-Daten; CAA beschränkt zulässige Zertifikatsaussteller. | Validierungskette, wirksame CAA-Verarbeitung und Zertifikatsbetrieb. Weder DNS-Verschlüsselung noch Schutz vor jeder Domain- oder Subdomainübernahme folgt daraus. |
| TLS und Zertifikate | TLS schützt den Übertragungskanal zwischen den beteiligten Endpunkten. | Vertrauensprüfung und die tatsächlich angebotenen Protokolle und Konfigurationen der relevanten Endpunkte. Ein einzelner Abruf beweist weder die gesamte Konfiguration noch die Sicherheit am Endpunkt. |
| Cache-Control | Steuert die Behandlung von Antworten durch HTTP-Caches. | Öffentliche und personalisierte Routen, gemeinsame und private Caches sowie weitere Speicher. no-store ist keine Zusage vollständiger Löschung oder Vertraulichkeit in jeder Umgebung. |
| Clear-Site-Data | Fordert unterstützende Browser zur Löschung bestimmter lokal gespeicherter Seitendaten auf. | Betroffene Datentypen, Browserwirkung und serverseitiger Sitzungs- und Datenlebenszyklus. Ein Header erledigt weder den serverseitigen Logout noch sämtliche gesetzlichen Löschpflichten. |
| Erweiterte Header | Können weitere, jeweils spezifische Browserregeln setzen. | Konkreter Mechanismus, aktuelle Unterstützung und Funktionsverträglichkeit. Aus der Sammelbezeichnung folgt keine Pflicht, sämtliche Mechanismen zu aktivieren. |
Technische Grundlagen sind unter anderem CSP Level 3, Abschnitte 3 und 6, HSTS, RFC 6797, Abschnitte 8 und 14.6, Fetch, Abschnitte 3.6–3.7, SRI, Abschnitte 3–5 und HTTP-Caching, RFC 9111, Abschnitt 5.2. Spezifikation und tatsächliche Browserunterstützung sind unterschiedliche Belege; die Tabelle behauptet keine hier durchgeführten Browsermessungen.
Sechs Regelwerke mit unterschiedlichen Anwendungsbereichen
NIS2 in Deutschland: Dienste und Organisation schützen
Die folgenden BSIG-Aussagen beziehen sich auf Deutschland. Der EU-Einstieg und die Länderinformationen helfen bei der Wahl des Rechtsraums. Den deutschen Prüfweg bündelt der Deutschland-Bereich.
Das deutsche Umsetzungsgesetz gilt grundsätzlich seit dem 6. Dezember 2025. Entscheidend sind § 28 BSIG, die Einrichtungsarten der Anlagen 1–2, Größenberechnung und Sonderregeln. Ein Unternehmen ist nicht allein deshalb erfasst, weil es eine Website betreibt oder einen regulierten Kunden beliefert. Die allgemeine Schwelle für wichtige Einrichtungen liegt bei mindestens 50 Beschäftigten oder mehr als 10 Mio. Euro sowohl Jahresumsatz als auch Jahresbilanzsumme, jeweils neben der passenden Einrichtungsart und weiteren Voraussetzungen. Größenunabhängige Sonderfälle bleiben zu prüfen. § 28 BSIG.
§ 30 verlangt angemessene und wirksame Maßnahmen sowie Dokumentation, aber keine universelle HTTP-Headerliste. Die Registrierung nach § 33 Abs. 1 ist grundsätzlich spätestens drei Monate nach erstmaliger oder erneuter Betroffenheit fällig; § 34 und das KRITIS-Übergangsrecht können hinzukommen. Die Leitung verantwortet Umsetzung und Überwachung nach § 38. NIS2-Checkliste, Meldepflicht.
Cyber Resilience Act: Produktpflichten und gestaffelte Termine
Die Verordnung (EU) 2024/2847 trat am 10. Dezember 2024 in Kraft. Ihre allgemeinen Pflichten gelten überwiegend ab 11. Dezember 2027; Kapitel IV gilt bereits seit 11. Juni 2026. Die Meldepflichten des Art. 14 gelten seit 11. September 2026, am hier geprüften Stichtag also bereits. Inkrafttreten und Anwendungsbeginn dürfen nicht gleichgesetzt werden. CRA, Art. 71.
Der CRA betrifft Produkte mit digitalen Elementen, die unter den Voraussetzungen des Art. 2 auf dem Markt bereitgestellt werden, einschließlich bestimmter für Produktfunktionen erforderlicher Datenfernverarbeitungslösungen. Das macht nicht jede Website oder beliebige SaaS-Leistung automatisch zum erfassten Produkt. Herstellerrolle, Produktbezug und Ausnahmen, etwa für bestimmte bereits sektoral geregelte Produkte, sind konkret zu prüfen. Art. 14 unterscheidet aktiv ausgenutzte Schwachstellen und schwerwiegende Sicherheitsvorfälle; Empfänger und Verfahren unterscheiden sich vom BSIG. Die Übergangsregeln des Art. 69 enthalten zudem eine ausdrückliche Erstreckung dieser Meldungen auf einschlägige Altprodukte. Ein Verweis auf „erst 2027“ kann deshalb zu spät sein. CRA, Art. 2–3, 14 und 69.
Ein Headerbefund kann bei der technischen Analyse eines Produkts helfen. Er entscheidet weder dessen CRA-Einordnung noch die Pflichterfüllung des Herstellers.
DORA: Finanzunternehmen und ihre IKT-Risiken
Die Verordnung (EU) 2022/2554 gilt seit dem 17. Januar 2025. Art. 2 nennt die erfassten Finanzunternehmen und Ausnahmen; Art. 9 betrifft Schutz und Prävention. Für Vorfälle gelten besondere Einstufungs- und Meldeverfahren. Ein Lieferant wird nicht allein durch einen Bankkunden zum Finanzunternehmen. Vertragliche Anforderungen nach Art. 28–30 und die gesonderte Einstufung kritischer IKT-Drittdienstleister nach Art. 31 sind auseinanderzuhalten. DORA, Art. 2, 9, 19, 28–31 und 64.
Header können zur sicheren Konfiguration beitragen. DORA verlangt darüber hinaus eine passende Organisation des IKT-Risikomanagements; ein öffentlicher Website-Check bestätigt weder die gesamte digitale operationale Resilienz noch die Aufsichtseinstufung eines Dienstleisters.
DSGVO: Sicherheit personenbezogener Daten
Die DSGVO ist seit dem 25. Mai 2018 anwendbar. Ihr sachlicher und räumlicher Anwendungsbereich folgt aus Art. 2 und 3. Art. 32 verpflichtet Verantwortliche und Auftragsverarbeiter zu einem risikogerechten Schutzniveau, einschließlich geeigneter Maßnahmen für Vertraulichkeit, Integrität, Verfügbarkeit, Wiederherstellung und regelmäßige Wirksamkeitsbewertung. Art. 25 betrifft Datenschutz durch Technikgestaltung und Voreinstellungen, Art. 5 Abs. 2 und Art. 24 die Rechenschaft beziehungsweise den Nachweis der Umsetzung. DSGVO, Art. 2–3, 5, 24–25, 32 und 99.
Eine Referrer-Policy kann eine unnötige Datenweitergabe begrenzen, sichere Cookies können Sitzungen unterstützen. Damit sind weder Rechtsgrundlage noch Informationspflichten, Auftragsverarbeitung oder die Voraussetzungen internationaler Datenübermittlungen erledigt. Ein „DSGVO-konform“-Urteil aus Headern ist deshalb unhaltbar.
Auch die Bußgeldrahmen sind zuzuordnen: Art. 83 Abs. 4 sieht für die dort genannten Verstöße, darunter Pflichten nach Art. 25–39, bis zu 10 Mio. Euro oder bei Unternehmen 2 % des weltweiten Vorjahresumsatzes vor, je nachdem, welcher Betrag höher ist. Abs. 5 nennt für andere Tatbestände bis zu 20 Mio. Euro oder 4 %. Das Fehlen eines Headers löst keinen dieser Beträge automatisch aus; Art. 83 Abs. 2 verlangt eine Bewertung des konkreten Falls.
IT-Grundschutz: konkrete Empfehlung mit eigenem Prüfrahmen
Das BSI-Kompendium Edition 2023, Baustein APP.3.1, Anforderung A21, empfiehlt geeignete HTTP-Response-Header. Es nennt CSP, HSTS, Content-Type, X-Content-Type-Options und Cache-Control sowie Cookieattribute. Die Formulierung ist eine Soll-Anforderung dieses Bausteins. Das ist ein greifbarer technischer Bezug, aber keine eigenständige allgemeine Gesetzespflicht jeder Website. BSI-Kompendium, APP.3.1.A21, Bausteinseite 5.
Für eine ISO-27001-Zertifizierung auf Basis von IT-Grundschutz bestimmen die Prüfgrundlagen das konkrete Verfahren. Die gelesene Version 4.8 vom 1. Februar 2026 nennt Edition 2023; maßgeblich ist der Auditbeginn. Ein vollständig gesetzter Headerbestand ersetzt weder dieses Verfahren noch die übrigen Maßnahmen. BSI-Prüfgrundlagen.
PCI DSS: Zahlungsintegration vor Headerliste
PCI DSS ist ein Branchenstandard für den Schutz von Zahlungskartendaten. Die gelesene aktive Ausgabe ist 4.0.1; die zunächst aufgeschobenen Anforderungen gelten seit 31. März 2025. Die Anforderungen 6.4.3 und 11.6.1 betreffen insbesondere autorisierte und integritätsgesicherte Zahlungsseiten-Scripts sowie Manipulationserkennung bei Scripts und sicherheitsrelevanten HTTP-Headern, wie sie beim Kundenbrowser ankommen. CSP oder SRI können dazu beitragen; ihr Vorhandensein belegt den vollständigen Prozess nicht. PCI SSC: Veröffentlichung 4.0.1, PCI SSC: Erläuterung zu Zahlungsseiten.
Der überarbeitete SAQ A enthält einen eigenen Nachweisweg: Die Einzelanforderungen wurden aus diesem Fragebogen entfernt, nicht aus dem Standard. Das erläuterte Script-Eignungskriterium betrifft eingebettete Zahlungsformulare, etwa iframes; es gilt so nicht für reine Weiterleitungen oder vollständig ausgelagerte Zahlung über einen Zahlungslink. Für eingebettete Formulare beschreibt PCI SSC technische Schutzwege oder die einschlägige Bestätigung des Zahlungsdienstleisters bei Umsetzung nach dessen Vorgaben. Klären Sie den passenden Fragebogen und Nachweisumfang mit der Stelle, die Ihren Nachweis entgegennimmt, typischerweise Acquirer oder Kartenorganisation. PCI SSC: SAQ-A-Änderung, FAQ 1588, Februar 2025.
Ein beliebiger vierteljährlicher Header-Scan ist kein daraus abgeleiteter universeller Prüfturnus und kein Ersatz für die nötige Manipulationserkennung. Prüfintervalle müssen zum einschlägigen Verfahren und Risiko passen.
TOM nachvollziehbar dokumentieren
TOM sind technische und organisatorische Maßnahmen. Für eine belastbare Dokumentation reichen die Worte „CSP vorhanden“ oder „TLS aktiv“ nicht. Verbinden Sie Schutzziel, betroffene Daten und Abläufe, konkrete Umsetzung, Ausnahmen, Prüfung und verantwortlichen Betrieb. Ein Beleg darf nur behaupten, was tatsächlich überprüft wurde.
Die folgenden synthetischen Dokumentationsbeispiele zeigen geeignete Formulierungen. Es wurden dafür keine produktiven Systeme geprüft. Die Beispiele beschreiben mögliche, überprüfbare Sachverhalte; sie sind keine fertige Bestätigung für Ihre Website.
Bei schmaler Ansicht können Sie die Tabelle seitlich scrollen.
| Maßnahme | Beispiel für einen präzisen Eintrag | Offen bleibt dabei |
|---|---|---|
| HTTPS mit HSTS | „Das fiktive Kundenportal portal.example verwendet HTTPS. In der angenommenen Prüfung waren HSTS und die betrachteten Weiterleitungen wirksam. Für Subdomains liegt noch keine vollständige Freigabe vor; includeSubDomains wird deshalb nicht als bereits abgesichert dokumentiert.“ | Vollständige TLS-Konfiguration, weitere Hosts, Erstkontakt und tatsächliche Preload-Aufnahme. |
| CSP | „Für das fiktive Bestellformular wird eine durchgesetzte CSP bewertet. Freigegebene Scripts und erforderliche Ausnahmen sind im zugehörigen Inventar erfasst. Ein Report-Only-Test wird getrennt vom produktiven Schutzstatus geführt.“ | Vollständige Anwendungssicherheit, korrekte Hashes oder Nonces und Wirkung aller relevanten Nutzerabläufe. |
| Sitzungs-Cookies | „Die angenommenen Prüfabläufe umfassen Anmeldung, Rollenwechsel und Abmeldung. Für die dabei beobachteten Sitzungs-Cookies sind Secure, HttpOnly und die begründete SameSite-Einstellung erfasst; serverseitiger Widerruf wird separat geprüft.“ | Nicht durchlaufene Abläufe, weitere Cookies und die rechtliche Zulässigkeit ihrer Verwendung. |
| Einbettungsschutz | „Das fiktive Verwaltungsportal soll nicht durch fremde Seiten eingebettet werden. Die wirksame frame-ancestors-Regel und gegebenenfalls X-Frame-Options werden an den Verwaltungsrouten geprüft; erlaubte Geschäftsintegrationen werden ausdrücklich erfasst.“ | Andere Routen und alle übrigen Angriffsarten. |
| Referrer-Begrenzung | „Für das fiktive Portal ist die gewählte Referrer-Policy dokumentiert. An ausgehenden Links und eingebundenen Ressourcen wird geprüft, welche Informationen übertragen werden. Personenbezogene Daten sollen unabhängig davon nicht in unnötigen URL-Parametern stehen.“ | Serverlogs, Drittanbieterverarbeitung und andere Übermittlungswege. |
| Ressourcenintegrität | „Für die mit SRI abgesicherten statischen Ressourcen werden erwartete Hashwerte, tatsächlich geprüfte Ressourcen und der Freigabeprozess bei Änderungen zusammengeführt. Dynamische oder nicht erfasste Scripts bleiben ausdrücklich außerhalb dieses Teilnachweises.“ | Vollständiges Scriptinventar, Autorisierung sämtlicher Scripts und kontinuierliche Manipulationserkennung. |
Für eigene Einträge ergänzen Sie die tatsächlich geprüften Ziele, Zeitpunkte, Methoden und Befunde sowie die verantwortliche Rolle und begründete nächste Prüfung. Kopieren Sie kein angenommenes „wirksam“ aus einem Beispiel in Ihre Dokumentation. Bei personenbezogenen Daten gehören eine angemessene Begrenzung der gespeicherten Belege, Zugriffsrechte und ein begründeter Aufbewahrungszweck dazu.
OWASP hilft bei der technischen Priorisierung
Die OWASP Top 10:2025 führen Security Misconfiguration als A02; in der vorherigen Ausgabe stand diese Kategorie an Position 5. A03:2025 behandelt Software Supply Chain Failures und umfasst mehr als nur bekannte Schwachstellen eingesetzter Komponenten. Das hilft bei der Wahl von Prüffragen, begründet aber keine gesetzliche Rangfolge und sagt nichts über den konkreten Befund Ihrer Anwendung aus. OWASP A02:2025, OWASP A03:2025.
Prüfen Sie daher nicht nur, ob Header gesetzt sind. Betrachten Sie auch sichere Voreinstellungen, nicht benötigte Funktionen, Versionspflege, Berechtigungen sowie Herkunft und Änderungen von Abhängigkeiten. Welche Maßnahme zuerst kommt, folgt aus Ihrem Risiko und den tatsächlich beobachteten Schwächen.
Häufige Fragen
Welche Header muss jede NIS2-Einrichtung setzen?
§ 30 BSIG enthält keine allgemeine Liste für jede HTTP-Antwort. Auswahl und Umsetzung hängen vom Dienst, Risiko und etwaigen Konkretisierungen ab. Eine technische Empfehlung aus einem bestimmten Prüfrahmen darf nicht ohne dessen Anwendungsbereich zur universellen Gesetzespflicht erklärt werden.
Bedeutet ein fehlender Header ein Bußgeld oder private Geschäftsführerhaftung?
Nein, der einzelne Befund beweist den Tatbestand nicht. § 65 BSIG differenziert die Verstöße und Höchstrahmen, unter anderem 10 beziehungsweise 7 Mio. Euro für bestimmte Pflichtverletzungen und Umsatzvarianten bei mehr als 500 Mio. Euro Gesamtumsatz. § 38 Abs. 2 betrifft davon getrennt schuldhaft verursachte Schäden der eigenen Einrichtung nach den anwendbaren Haftungsregeln. Geschäftsleitungsverantwortung und Haftung.
Brauche ich alle Sicherheitsheader für PCI DSS?
Eine pauschale Kombination aller Header folgt daraus nicht. Ordnen Sie Zahlungsintegration, erfasste Scripts, Schutzprozesse und geeigneten Nachweisweg zu. Der oben erläuterte Unterschied zwischen iframe und Weiterleitung ist dafür wichtiger als eine vollständige Headerliste.
Was leistet ein Wolf-Agents-Ergebnis?
Der Web-Security-Check kann ausgewählte öffentlich sichtbare Antwortmerkmale und Befunde festhalten. Er prüft nicht alle Routen, Loginzustände, Cookies oder im Kundenbrowser ausgeführten Scripts. Er ist kein vollständiger Penetrationstest, keine laufende Überwachung und kein Konformitätsnachweis. Dokumentieren Sie seine Ergebnisse als begrenzte Momentaufnahme und ergänzen Sie die zum jeweiligen Schutzziel passenden Prüfungen.
Vom technischen Befund zur überprüften Maßnahme
Beginnen Sie mit einer relevanten Anwendung und einem konkreten Risiko. Halten Sie fest, welche Browserregel helfen soll, setzen Sie sie kontrolliert um und prüfen Sie den tatsächlichen Ablauf einschließlich möglicher Funktionsstörungen. Ordnen Sie den Beleg danach in Ihre Sicherheitsdokumentation ein.
Weiterführend: NIS2-Checkliste, NIS2 und ISO 27001, E-Mail-Sicherheit und Compliance und Übersicht der Web-Security-Themen.