Security Headers prüfen: HSTS, Frame-Schutz und CSP im Response

Der Check liest drei Header der geprüften Seite: HSTS, X-Frame-Options oder frame-ancestors und eine Content Security Policy. Fehlt einer, ist die Zeile „zu prüfen“.

Was wird geprüft

Der Scan liest die Antwort-Header der geprüften URL nach dem letzten Redirect. Drei Dinge zählen: Strict-Transport-Security, ein Schutz gegen Framing (X-Frame-Options oder eine CSP mit frame-ancestors) und eine Content-Security-Policy. Alle drei gesetzt heißt „ok“. Fehlt eines, nennt die Zeile, was da ist und was fehlt, und ist „zu prüfen“. Fehlen alle, ebenfalls „zu prüfen“, mit dem Vermerk „schwache Baseline“.

Was der Scan nicht bewertet: den Inhalt der Header. Eine CSP mit default-src * zählt als gesetzt, ein HSTS mit einer Sekunde Laufzeit auch. Weitere Header wie Referrer-Policy, Permissions-Policy oder X-Content-Type-Options bleiben außen vor, ebenso Unterseiten und statische Assets, die ein CDN mit anderen Headern ausliefern kann.

Warum ist das wichtig

Die CSP ist der Header, an dem Tracking und IT sich begegnen. Sie entscheidet, welche Skripte laufen, und jeder neue Tag-Endpunkt muss darin stehen: der Tag Manager, der Server-Side-Container unter der eigenen Subdomain, das CMP, die Pixel danach. Fehlt ein Eintrag, blockiert der Browser still, der Datenfluss reißt ab, und im Reporting sieht das aus wie ein Kampagnenproblem. Wir haben es selbst erlebt: Auf datascale.de fehlte wochenlang data: in der script-src der Live-Konfiguration, während das Repository die richtige Policy trug. Der Unterschied war nur am Response sichtbar, nirgends im Code.

HSTS sorgt dafür, dass der Browser die Seite nach dem ersten Besuch nie wieder über HTTP anfragt. Der Frame-Schutz verhindert, dass jemand Ihre Seite in einen fremden Frame lädt und Klicks abgreift. Beides ist Baseline, kein Projekt.

Häufige Ursachen

Der Hoster liefert Default-Header aus, eine Security-Policy hat nie jemand konfiguriert.
Eine CSP existierte, wurde nach Frontend-Fehlern aber komplett entfernt statt repariert.
Proxy oder CDN überschreiben die vom Backend gesetzten Header beim Ausliefern, oder setzen sie nur für dynamische Seiten, nicht für statisch gecachte.
Die Header stehen in der Anwendung, die statischen Seiten kommen aber direkt vom Webserver oder vom Edge und tragen sie nicht.

So beheben

Die Header dort setzen, wo jede Antwort durchläuft, in der Regel am Reverse Proxy oder CDN, nicht in der Anwendung. Reihenfolge: Strict-Transport-Security mit mindestens einem Jahr Laufzeit, dann frame-ancestors 'self' in der CSP, dann die CSP selbst, zunächst als Content-Security-Policy-Report-Only mit allen Tag-Endpunkten, nach einer Woche ohne Verstöße scharf. Dann curl -I gegen die Live-Domain. Nicht die Konfigurationsdatei lesen, den Response. Ein Grade B auf securityheaders.com ist ein realistisches Ziel für eine Marketing-Site; A verlangt eine strenge CSP, die jeden neuen Tag zum Ticket macht.

Erst selbst prüfen

Der Tracking-Check testet diesen Punkt zusammen mit allen anderen in Sekunden.

Tracking-Check starten →

Verwandte Checks

HTTPS →Meta-Tags →Third-Party-Scripts →

Häufige Fragen

Warum prüft ein Tracking-Check überhaupt Security-Header?

Wegen der CSP. Eine Content Security Policy entscheidet, welche Skripte der Browser ausführt, und damit, ob Tag Manager, Consent-Plattform und Server-Side-Endpunkt überhaupt laden. Eine CSP, die den neuen Tagging-Server nicht kennt, schaltet das Tracking still ab; im Dashboard sieht das aus wie ein Conversion-Einbruch. Die anderen beiden Header sind die Baseline, die jedes Audit ohnehin abfragt.

Wir haben eine CSP, aber sie bricht unser Tracking. Was tun?

Zuerst im Report-Only-Modus fahren: Der Browser meldet Verstöße, blockiert aber nichts. Dann die Tag-Endpunkte aufnehmen: den Tag Manager, den eigenen Tagging-Server, das CMP-CDN und die Pixel, die nach Einwilligung laden. Für Inline-Snippets einen Nonce statt „unsafe-inline“. Erst wenn der Report leer ist, die Policy scharf schalten.

Reicht X-Frame-Options, oder brauchen wir frame-ancestors?

Beides erfüllt den Check. „frame-ancestors“ in der CSP ist der moderne Weg und erlaubt mehr als „SAMEORIGIN“ oder „DENY“, etwa einzelne Partnerdomains. Wer beide setzt, sollte sie deckungsgleich halten; bei Widerspruch folgen aktuelle Browser der CSP.

Behebung

Verdrahtet in Tagen, nicht in Sprints.

Befunde aus dem Tracking-Check gehen im Audit Sprint in eine Reihenfolge mit Aufwand, jeder Baustein mit Abnahmekriterium.

Zur Leistung Audit Sprint anfragen