Ein Online-Shop kann technisch einwandfrei laufen und trotzdem eine offene Flanke haben, die im HTTP-Verkehr steckt: in den Antwort-Headern, die der Server bei jeder Seite mitschickt. HTTP-Security-Header wie Content-Security-Policy und Strict-Transport-Security weisen den Browser an, ganze Angriffsklassen von vornherein zu unterbinden -- vom eingeschleusten Fremd-Skript bis zum unverschlüsselten Erstaufruf. Trotzdem sind sie selten gesetzt: Nur rund 22 Prozent aller Hosts liefern überhaupt eine Content-Security-Policy aus (HTTP Archive Web Almanac 2025). Noch heikler ist, dass diese Header kein Einmal-Setup sind. Jedes Theme-, Plugin- oder Payment-Update kann eine bestehende Policy brechen oder ein neues externes Skript einschleusen, das die Richtlinie stillschweigend aushebelt. Der Payment-Card-Standard hat darauf reagiert und verlangt seit dem 31. März 2025 ein Inventar aller Skripte auf der Zahlungsseite samt Überwachung auf unautorisierte Änderungen (PCI Security Standards Council). Dieser Beitrag zeigt, welche Header ein Shop setzen sollte, wie der Weg vom risikolosen Report-only-Modus zum scharfen Enforce führt und warum die laufende Header-Pflege samt Regressionsprüfung in jede Sicherheitsupdate-Betreuung gehört.
Das Wichtigste in Kürze
- Security-Header liegen in der Server- oder Anwendungskonfiguration, nicht im Code eines Plugins: Ein Shop-Update aktualisiert sie nicht mit, kann sie aber still unwirksam machen. Nur 22 Prozent (HTTP Archive Web Almanac 2025) aller Hosts liefern überhaupt eine CSP aus.
- Der Grundschutz umfasst sechs Header: Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options mit nosniff, Referrer-Policy als strict-origin-when-cross-origin, Permissions-Policy für ungenutzte Browser-Funktionen sowie X-Frame-Options oder frame-ancestors.
- Eine CSP begrenzt, woher Skripte laden und wohin Daten fließen dürfen, verliert diesen Schutz aber mit unsafe-inline, das über 92 Prozent (HTTP Archive Web Almanac 2025) der Seiten mit CSP verwenden. Inline-Skripte werden per nonce oder Inhalts-Hash freigegeben.
- HSTS erzwingt HTTPS und schließt das Fenster des unverschlüsselten Erstaufrufs. includeSubDomains macht jede Subdomain ohne sauberes HTTPS unerreichbar, und ein preload-Eintrag lässt sich nur mit langem Vorlauf zurücknehmen, deshalb beginnt man mit kurzer max-age.
- Der Einstieg läuft über Content-Security-Policy-Report-Only: Verstöße sammeln, jede gemeldete Quelle bewerten, Richtlinie schärfen, in Staging gegenprüfen, dann durchsetzen. Nur rund 1,8 Prozent (HTTP Archive Web Almanac 2024) der Seiten nutzen diesen Messmodus.
- Themes, Extensions und Payment-Skripte verschieben die geladenen Quellen, deshalb folgt jedem Update eine Regressionsprüfung. PCI DSS 4.0 verlangt seit dem 31. März 2025 ein Skript-Inventar der Zahlungsseite (6.4.3) und eine Prüfung mindestens alle sieben Tage (11.6.1).
Warum Security-Header kein Einmal-Setup sind
Ein Security-Header ist eine kurze Anweisung im HTTP-Antwortkopf -- eine Textzeile, die der Browser liest, bevor er die Seite darstellt. Sie kostet kaum Rechenzeit, verlangsamt den Shop nicht und lässt sich mit wenigen Zeilen in der Server-Konfiguration setzen. Gerade weil der Aufwand so gering ist, überrascht die niedrige Verbreitung: Selbst dort, wo eine Content-Security-Policy existiert, ist sie oft aufgeweicht. Über 92 Prozent (HTTP Archive Web Almanac 2025) der Seiten mit CSP erlauben unsafe-inline und heben damit einen zentralen Schutz gegen Cross-Site-Scripting weitgehend auf. Ein Header ist eben kein Produkt-Feature, das man einmal aktiviert, sondern Konfiguration -- und Konfiguration verschiebt sich mit jeder Änderung am System.
Das Tückische liegt im Zusammenspiel mit dem laufenden Betrieb. Ein neues Theme bindet eine Schriftart von einer fremden Adresse ein, eine aktualisierte Extension lädt plötzlich ein zusätzliches Analyse-Skript, ein Payment-Anbieter stellt sein Widget auf eine neue Domain um -- und schon blockiert eine zuvor korrekte Content-Security-Policy legitime Funktionen, oder eine zu locker gefasste Regel lässt das neue Fremd-Skript ungeprüft passieren. Ohne Kontrolle nach jeder Aktualisierung zerfällt eine einmal erreichte Härtung still. Genau deshalb behandeln wir Header wie jede andere sicherheitsrelevante Einstellung: als Teil eines fortlaufenden Prozesses, der bei jedem Wartungsfenster ohne Umsatzausfall mitgedacht wird.
Header sind Konfiguration, kein Feature
Die wichtigsten Header im Überblick
Welche Header sinnvoll sind, muss man nicht neu erfinden. Das OWASP Secure Headers Project pflegt eine anbieterunabhängige Referenz, welche HTTP-Antwort-Header die Sicherheit erhöhen und wie sie konfiguriert werden sollten (OWASP Secure Headers Project). Ergänzend beschreiben die Mozilla MDN Web Docs jeden Header samt Direktiven und Browser-Verhalten im Detail (Mozilla MDN Web Docs). Aus beiden lässt sich eine Basis ableiten, die für die meisten Shops trägt -- fünf bis sechs Header, die zusammen einen belastbaren Grundschutz bilden.
| Header | Schützt vor | Empfohlener Einstieg |
|---|---|---|
| Content-Security-Policy | Cross-Site-Scripting, eingeschleusten Fremd-Skripten | Restriktiv, zunächst im Report-only-Modus |
| Strict-Transport-Security | Protokoll-Downgrade, unverschlüsseltem Erstaufruf | max-age=63072000; includeSubDomains |
| X-Content-Type-Options | MIME-Sniffing auf falsch interpretierte Dateien | nosniff |
| Referrer-Policy | Abfluss von URL-Daten an Dritte | strict-origin-when-cross-origin |
| Permissions-Policy | ungewolltem Zugriff auf Kamera, Mikrofon, Standort | nicht benötigte Funktionen leer setzen |
| X-Frame-Options | Clickjacking durch Einbettung in fremde Seiten | SAMEORIGIN bzw. CSP frame-ancestors |
Die Verbreitung dieser Header ist sehr ungleich. Am häufigsten ist X-Content-Type-Options mit nosniff mit knapp 50 Prozent vertreten (HTTP Archive Web Almanac 2025), gefolgt von X-Frame-Options mit etwa 37 Prozent (HTTP Archive Web Almanac 2024) und HTTP Strict Transport Security mit rund 36 Prozent (HTTP Archive Web Almanac 2025). Deutlich seltener sind die Referrer-Policy mit rund 17 Prozent (HTTP Archive Web Almanac 2024) und die vergleichsweise junge Permissions-Policy mit nur 3,7 Prozent (HTTP Archive Web Almanac 2025). Für einen Shop bedeutet das: Die einfachen, risikoarmen Header wie nosniff sind schnell gesetzt, während die wirkungsvollsten -- CSP und HSTS -- die meiste Sorgfalt verlangen.
Content-Security-Policy: wirksam, aber heikel
Die Content-Security-Policy ist der wirksamste der Header und zugleich der anspruchsvollste. Sie legt fest, aus welchen Quellen der Browser Skripte, Stile, Bilder und weitere Ressourcen laden darf und wohin die Seite Daten senden kann. Ein per Sicherheitslücke eingeschleustes Skript, das Zahlungsdaten an eine fremde Domain schicken will, scheitert an einer restriktiven connect-src-Regel -- selbst wenn der Angreifer es geschafft hat, Code in die Seite zu bringen. Die Mozilla MDN Web Docs beschreiben CSP als zusätzliche Schutzschicht, die bestimmte Angriffe wie Cross-Site-Scripting und Dateninjektion erkennt und abschwächt (Mozilla MDN Web Docs).
Der häufigste Fehler ist die Direktive unsafe-inline. Sie erlaubt beliebige Inline-Skripte und macht damit genau die Lücke wieder auf, die CSP schließen soll -- und trotzdem greifen über 92 Prozent der Seiten mit CSP zu ihr (HTTP Archive Web Almanac 2025). Der saubere Weg führt über nonce- oder hash-basierte Freigaben: Jedes legitime Skript erhält einen einmaligen Zufallswert oder einen Inhalts-Hash, und nur damit ausgezeichnete Skripte laufen. Das OWASP Secure Headers Project empfiehlt, eine CSP so restriktiv wie möglich zu halten und Ausnahmen bewusst und dokumentiert zu setzen (OWASP Secure Headers Project).
# Content-Security-Policy mit nonce statt unsafe-inline
add_header Content-Security-Policy "\
default-src 'self'; \
script-src 'self' 'nonce-$request_id' https://pay.example.com; \
style-src 'self'; \
img-src 'self' data:; \
connect-src 'self' https://pay.example.com; \
frame-ancestors 'self'; \
object-src 'none'; \
base-uri 'self'; \
report-uri /csp-report" always;
# Zum Messen ohne Blockieren: gleiche Policy als Report-Only
# add_header Content-Security-Policy-Report-Only "..." always;unsafe-inline hebelt die CSP aus
unsafe-inline im script-src bietet kaum noch Schutz vor Cross-Site-Scripting, weil sie beliebige eingebettete Skripte erlaubt. Wo Inline-Skripte unvermeidbar sind, gehören sie über einen nonce oder einen Inhalts-Hash freigegeben -- nicht pauschal. Genau diese Unterscheidung entscheidet, ob eine CSP wirkt oder nur existiert.HSTS: HTTPS erzwingen, ohne sich auszusperren
HTTP Strict Transport Security weist den Browser an, eine Domain ausschließlich über HTTPS aufzurufen -- auch dann, wenn ein Nutzer die Adresse ohne https:// eingibt oder einem alten http://-Link folgt. Damit schließt HSTS das Zeitfenster des unverschlüsselten Erstaufrufs, in dem ein Angreifer im selben Netz die Verbindung umleiten könnte. Die drei zentralen Bestandteile beschreiben die Mozilla MDN Web Docs: max-age legt die Gültigkeitsdauer in Sekunden fest, includeSubDomains dehnt die Regel auf alle Subdomains aus und preload meldet die Domain für die im Browser fest hinterlegte Vorabliste an (Mozilla MDN Web Docs).
Gerade includeSubDomains und preload verlangen Sorgfalt. Wer die Regel auf alle Subdomains ausdehnt, muss sicherstellen, dass wirklich jede Subdomain -- auch interne Werkzeuge und Altsysteme -- sauber über HTTPS erreichbar ist, sonst werden sie unerreichbar. Und ein preload-Eintrag lässt sich nur mit erheblichem Vorlauf wieder zurücknehmen. Deshalb beginnt HSTS sinnvoll mit einer kurzen max-age, die nach erfolgreichem Test schrittweise erhöht wird. Die Transportverschlüsselung selbst -- Zertifikate, Protokollversionen und Erneuerung -- behandelt der Beitrag zur Verwaltung von SSL-Zertifikaten ausführlicher.
includeSubDomains und preload mit Bedacht
includeSubDomains und preload ist schwer rückgängig zu machen: Browser merken sich die Anweisung für die gesamte max-age-Dauer, ein Preload-Eintrag zusätzlich fest im Browser. Wer die Header über eine kurze Gültigkeitsdauer einführt und erst nach erfolgreichem Test verlängert, vermeidet, sich selbst oder einzelne Subdomains auszusperren.# HTTPS erzwingen (nach Test schrittweise verlaengern)
add_header Strict-Transport-Security "max-age=63072000; includeSubDomains" always;
# MIME-Sniffing unterbinden
add_header X-Content-Type-Options "nosniff" always;
# URL-Daten sparsam mitgeben
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
# Clickjacking erschweren
add_header X-Frame-Options "SAMEORIGIN" always;
# Nicht benötigte Browser-Funktionen abschalten
add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;Der Report-only-zu-Enforce-Prozess
Eine Content-Security-Policy scharf zu schalten, ohne zu wissen, was der Shop tatsächlich lädt, endet zuverlässig in blockierten Skripten und einem gestörten Checkout. Deshalb gibt es den Report-only-Modus. Über den Header Content-Security-Policy-Report-Only teilt der Browser jede Verletzung der Richtlinie per Bericht mit, blockiert aber nichts -- der Shop läuft unverändert weiter, während man beobachtet, welche Quellen die Richtlinie brechen würden (Mozilla MDN Web Docs). Genutzt wird dieser Modus kaum: Nur rund 1,8 Prozent der Seiten setzen eine CSP überhaupt im Report-only-Modus ein (HTTP Archive Web Almanac 2024), obwohl er der sicherste Einstieg ist.
- Ist-Zustand erfassen: die Richtlinie zunächst nur als
Content-Security-Policy-Report-Onlyausliefern und die gemeldeten Verstöße über einen definierten Zeitraum sammeln. - Quellen bewerten: jede gemeldete Quelle prüfen -- gehört sie zum Shop, ist sie legitim und nötig, oder ist sie ein Kandidat zum Entfernen?
- Richtlinie schärfen: legitime Quellen explizit freigeben, Inline-Skripte über
nonceoder Hash stattunsafe-inlineerlauben, alles andere ausschließen. - In einer Staging-Umgebung gegenprüfen: die verschärfte Richtlinie zunächst abseits des Live-Betriebs testen, wie es der Beitrag zu Staging-Umgebungen für sichere Updates beschreibt.
- Enforce schalten: die Richtlinie als durchsetzenden
Content-Security-Policy-Header aktivieren -- mit weiterhin aktivem Report-Kanal, um Regressionen früh zu sehen.
Report-only misst, Enforce schützt
Warum jedes Update eine Policy brechen kann
Ist eine Policy einmal scharf, beginnt die eigentliche Daueraufgabe. Ein Shop ist kein statisches Gebilde: Themes werden aktualisiert, Extensions kommen hinzu, Zahlungsdienstleister ändern ihre Einbindung, Consent- und Analyse-Werkzeuge laden neue Ressourcen nach. Jede dieser Änderungen kann zwei Dinge tun -- eine bestehende Regel brechen, sodass legitime Funktionen blockiert werden, oder eine neue externe Quelle einführen, die eine zu weit gefasste Richtlinie ungeprüft durchlässt. Der Payment-Card-Standard adressiert genau das: Anforderung 6.4.3 verlangt ein vollständiges Inventar aller Skripte auf der Zahlungsseite, jedes autorisiert, in seiner Integrität abgesichert und mit dokumentierter Begründung (PCI Security Standards Council). Ein solches Inventar ist nur haltbar, wenn es bei jeder Änderung mitgeführt wird.
Theme- und Template-Updates
Ein neues Theme bindet oft Schriften, Icons oder Skripte von zusätzlichen Adressen ein. Eine bestehende CSP blockiert sie -- oder muss um genau diese Quellen erweitert werden, bevor die Seite wieder vollständig funktioniert.
Plugins und Extensions
Eine aktualisierte Extension lädt mitunter neue externe Bibliotheken nach. Ohne Abgleich mit der Richtlinie bricht entweder die Funktion oder die Absicherung -- und niemand bemerkt es sofort.
Payment und 3-D-Secure
Zahlungsdienstleister und 3-D-Secure-Flüsse laden Skripte und leiten teils auf weitere Domains um. Ändert sich diese Einbindung, muss die Richtlinie folgen, sonst bricht die Zahlung oder ein fremdes Skript rutscht durch.
Consent- und Analyse-Skripte
Consent-Banner und Analyse-Werkzeuge binden Ressourcen dynamisch ein und ändern ihre Quellen ohne Vorwarnung. Sie sind ein häufiger Grund, warum eine gestern gültige CSP heute Verstöße meldet.
Am Checkout verschärft sich dieses Problem, weil dort Zahlungsdaten im Spiel sind. Wie eingeschleuste oder manipulierte Skripte am Checkout konkret zu Datenabfluss führen und wie Subresource Integrity und eine restriktive CSP das verhindern, behandelt der Beitrag zu Web-Skimming am Checkout. Für regulierte Betreiber kommt hinzu, dass Sicherheitsmaßnahmen zunehmend nachzuweisen sind -- ein Aspekt, den auch die NIS2-Pflichten für Online-Shops berühren.
Header-Pflege und Regressionsprüfung
Die Konsequenz aus all dem ist eine wiederkehrende Prüfung: Nach jedem größeren Update wird kontrolliert, ob die gesetzten Header noch vorhanden, noch passend und noch wirksam sind. Der Payment-Card-Standard gibt dafür in Anforderung 11.6.1 einen Mindesttakt vor -- eine Erkennung unautorisierter Änderungen an Skripten und sicherheitsrelevanten HTTP-Headern der Zahlungsseite, die mindestens alle sieben Tage prüft (PCI Security Standards Council). Sieben Tage sind das Minimum, nicht das Ziel: Bei durchschnittlich 119 neuen Schwachstellen pro Tag im Zeitraum Juli 2024 bis Juni 2025 (BSI Lagebericht 2025) ist ein enger Takt bis hin zur kontinuierlichen Prüfung der sinnvollere Weg. Diese Beobachtung lässt sich über ein laufendes Monitoring der Antwort-Header automatisieren.
- Nach jedem Theme-, Plugin- oder Payment-Update prüfen, ob alle gesetzten Header noch ausgeliefert werden und keine neue externe Quelle unbemerkt hinzugekommen ist.
- Die Content-Security-Policy gegen die tatsächlich geladenen Ressourcen abgleichen und neue legitime Quellen bewusst und dokumentiert freigeben.
-
unsafe-inlineund andere Aufweichungen gezielt zurückbauen und durchnonce- oder Hash-Freigaben ersetzen. - Die HSTS-Gültigkeitsdauer und
includeSubDomainsregelmäßig gegen den tatsächlichen Subdomain-Bestand prüfen. - Das Skript-Inventar der Zahlungsseite versioniert führen und bei jeder Änderung neu freigeben (PCI DSS 4.0, Anforderung 6.4.3).
- Header-Änderungen wie Code behandeln: versioniert, nachvollziehbar und über eine Staging-Umgebung getestet, bevor sie live gehen.
Ein Security-Header wird selten durch einen Angriff unwirksam, sondern durch das eigene nächste Update. Wer Header wie Code behandelt und nach jeder Änderung nachmisst, hält den Schutz, statt ihn still zu verlieren.
Ein sauber gesetztes Header-Set, ein dokumentierter Report-only-zu-Enforce-Prozess und eine feste Regressionsprüfung nach jedem Update ergeben zusammen einen Schutz, der nicht mit dem nächsten Deployment zerfällt. Genau diese laufende Header-Pflege ist bei uns fester Bestandteil der laufenden Sicherheitsupdates und greift in die übrigen Bausteine der Wartung -- von der Server-Härtung für Shops über das Patch- und CVE-Management bis zu Regressionstests nach Updates. Als Teil eines SLA-Wartungsvertrags und unserer gesamten Managed-Wartungsleistungen wird aus einer einmal gesetzten Policy ein Zustand, der über jede Aktualisierung hinweg gepflegt bleibt. Wie das im laufenden Shopware-Betrieb aussieht, besprechen wir gern im Detail.
nosniff, Referrer-Policy, Permissions-Policy und X-Frame-Options beziehungsweise frame-ancestors in der CSP. Das OWASP Secure Headers Project und die Mozilla MDN Web Docs beschreiben diese Header und ihre empfohlene Konfiguration im Detail (OWASP Secure Headers Project). CSP und HSTS sind dabei die wirkungsvollsten und verlangen die meiste Sorgfalt.Content-Security-Policy-Report-Only aus. Der Browser meldet jede Verletzung, blockiert aber nichts -- der Shop läuft unverändert weiter (Mozilla MDN Web Docs). So lässt sich messen, welche Quellen eine Seite wirklich lädt, bevor die Richtlinie im Enforce-Modus scharf geschaltet wird. Genutzt wird der Modus bislang selten, nur rund 1,8 Prozent der Seiten setzen ihn ein (HTTP Archive Web Almanac 2024).