Sicherheits-Header prüfen
Gib eine Adresse ein. Du bekommst die sechs Header, auf die es ankommt, jeden mit dem, was sein Wert wirklich erreicht — und was da ist und nichts tut, wird gesagt.
Warum „vorhanden“ keine Note ist
Alle anderen Prüfer benoten nach Anwesenheit: der Header ist da, grün. Ein Header kann aber da sein und überhaupt nichts tun — max-age=0 ist der dokumentierte Weg, HSTS abzuschalten, eine Richtlinie im Report-Only-Modus meldet und blockiert nicht, und frame-ancestors sorgt dafür, dass der Browser dein X-Frame-Options vollständig ignoriert. Alle drei lesen sich wie erledigt. Und das ist schlimmer als ein fehlender, denn einen Header, den man sieht, hört man auf zu prüfen.
Was dir das nicht sagt
Ob deine Seite sicher ist. Diese Header begrenzen, was ein Angriff anrichten kann, wenn schon etwas schiefgegangen ist; gegen den Fehler, der ihn hereinließ, tun sie nichts. Sechs perfekte Header sitzen bestens auf einem ungepatchten CMS.
Wenn du hier bist, kommt meist das hier als Nächstes
Ein Foto, oder der ganze Film
So steht die Seite gerade jetzt da. Die Überwachung schaut hin — Zertifikat, DNS, Erreichbarkeit — und meldet sich an dem Tag, an dem sich etwas ändert, meist der Tag, an dem jemand eine Konfiguration ausgerollt hat, die er nicht gelesen hat.
Häufige Fragen
- Es sagt, mein Header tue nichts. Ich sehe ihn doch in der Antwort.
- Wir auch — genau darum geht es. Drei davon stehen draußen ständig vorhanden und wirkungslos herum: HSTS mit max-age=0 (das ist die Anweisung, es zu vergessen), eine Content-Security-Policy, die nur als Report-Only geschickt wird (sie meldet, blockiert nichts), und ein X-Frame-Options auf einer Seite, deren Richtlinie zusätzlich frame-ancestors führt, an das sich der Browser hält. Der Wert steht im Bericht; vergleich ihn mit dem, was du gesetzt zu haben glaubtest.
- Brauche ich alle sechs?
- Fünf davon sind je eine Zeile Konfiguration, und es gibt keinen Grund, sie wegzulassen. Die Content-Security-Policy ist die, die echte Arbeit macht, denn eine strenge zerlegt dir die Inline-Skripte, bis du sie reparierst — und sie ist zugleich die einzige, die den Schaden eines XSS begrenzt, statt auf Verhinderung zu hoffen. Die rollt man erst im Report-Only-Modus aus, liest die Meldungen und schaltet sie dann scharf.
- Warum ist unsafe-inline ein Problem, wenn der Rest zu ist?
- Weil es genau das ist, wogegen eine CSP existiert. Mit unsafe-inline in script-src läuft ein eingeschleustes script-Tag — und das ist der ganze Angriff. Alles andere, was die Richtlinie einschränkt, wiegt weniger als diese eine Lücke. Der Ausweg sind Nonces oder Hashes, und mit strict-dynamic darfst du unsafe-inline als Rückfall für alte Browser behalten, ohne dass es gegen dich zählt.