Naar de inhoud

Beveiligingsheaders controleren

Typ een adres. Je krijgt de zes headers die ertoe doen, elk met wat zijn waarde echt bereikt — en wat er staat zonder iets te doen, wordt gezegd.

Waarom “aanwezig” geen cijfer is

Alle andere controleurs geven punten voor aanwezigheid: de header staat er, groen. Maar een header kan er staan en helemaal niets doen — max-age=0 is de gedocumenteerde manier om HSTS uit te zetten, een beleid in Report-Only meldt en blokkeert niet, en frame-ancestors zorgt dat de browser je X-Frame-Options volledig negeert. Alle drie lezen als af. En dat is erger dan een ontbrekende, want een header die je ziet is een header die je niet meer nakijkt.

Wat dit je niet vertelt

Of je site veilig is. Deze headers beperken wat een aanval kan aanrichten zodra er iets is misgegaan; tegen het lek dat hem binnenliet doen ze niets. Zes perfecte headers zitten prima boven op een nooit bijgewerkt CMS.

Eén foto, of de hele film

Zo staat de site er nu bij. De bewaking kijkt mee — het certificaat, het DNS, de bereikbaarheid — en laat het weten op de dag dat er iets verandert, meestal de dag dat iemand een configuratie uitrolde die hij niet had gelezen.

Bekijk de bewaking →

Veelgestelde vragen

Er staat dat mijn header niets doet. Ik zie hem toch in het antwoord.
Wij ook — dat is nu juist het punt. Drie hiervan staan in het wild voortdurend aanwezig én werkeloos: HSTS met max-age=0 (dat is het bevel om het te vergeten), een Content-Security-Policy die alleen als Report-Only wordt gestuurd (die meldt, blokkeert niets), en een X-Frame-Options op een site waarvan het beleid ook frame-ancestors draagt, waar de browser zich aan houdt. De waarde staat in het rapport; leg hem naast wat je dacht te hebben gezet.
Heb ik alle zes nodig?
Vijf zijn elk één regel configuratie en er is geen reden ze weg te laten. De Content-Security-Policy is degene die echt werk kost, want een strenge sloopt je inline scripts totdat je ze opknapt — en het is ook de enige die de schade van een XSS beperkt in plaats van te hopen hem te voorkomen. Die rol je eerst uit in Report-Only, je leest de meldingen, en dan zet je hem aan.
Waarom is unsafe-inline een probleem als de rest dicht is?
Omdat het precies is waarvoor een CSP bestaat. Met unsafe-inline in script-src draait een ingespoten script-tag — en dat is de hele aanval. Al het andere dat het beleid beperkt weegt minder dan dat ene gat. De uitweg zijn nonces of hashes, en met strict-dynamic mag je unsafe-inline houden als terugval voor oude browsers zonder dat het tegen je telt.