Gidsen
HTTP-beveiligingsheaders auditen
Headers beperken specifieke browserrisico's maar bewijzen geen totale veiligheid.
Start met HTTPS, daarna CSP, framebeveiliging, nosniff en referrer; ontbreken vraagt controle, niet de conclusie dat er is ingebroken.
Transportlaag beveiligen met HTTPS en HSTS
Verzend al het openbare dataverkeer via HTTPS met geldige certificaten. Stel de header Strict-Transport-Security in met een positieve looptijd (zoals max-age=31536000). Vermijd max-age=0, omdat dit het HSTS-beleid volgens RFC 6797 direct wist en de bescherming voor toekomstige bezoeken opheft.
Een restrictief Content-Security-Policy opstellen
Stel CSP in via HTTP-responskoppen om het uitvoeren van scripts en het laden van externe bronnen strikt te beperken. Vermijd onveilige instructies zoals 'unsafe-inline' en 'unsafe-eval' ten gunste van nonces of hashes, en definieer frame-ancestors om framing te reguleren.
Beschermen tegen clickjacking en MIME-sniffing
Configureer frame-ancestors in CSP (en X-Frame-Options: DENY voor oudere browsers) om ongeoorloofd insluiten in frames te voorkomen. Stel verplicht X-Content-Type-Options: nosniff in, zodat browsers verklaarde MIME-typen strikt respecteren en geen uitvoerbare bestanden raden.
Cross-origin isolatie en privacy-headers inzetten
Volledige cross-origin isolatie vereist gelijktijdig Cross-Origin-Opener-Policy: same-origin en Cross-Origin-Embedder-Policy: require-corp (of credentialless). Vul dit aan met Referrer-Policy: strict-origin-when-cross-origin en een restrictieve Permissions-Policy voor ongebruikte browserfuncties.
Grenzen van de header-audit transparant benoemen
Een inspectie van beveiligingsheaders is een belangrijk onderdeel van defense-in-depth, maar vervangt geen penetratietest. Kwetsbaarheden in backend-code, databasequery's, authenticatie en bedrijfslogica vereisen afzonderlijke, gespecialiseerde beveiligingscontroles.