HTTP-beveiligingsheaders uitgelegd: HSTS, CSP en meer

Wat beveiligingsheaders zijn

Elke HTTP-respons begint met headers: paren van naam en waarde, zoals Content-Type: text/html. Een handvol daarvan verandert hoe de browser de pagina behandelt. Ze kosten niets om te versturen, gelden voor elke bezoeker en worden ingesteld op de server, het hostingplatform of een contentdeliverynetwerk, niet in de HTML van de pagina.

IPNixa stelt zijn eigen headers in via een _headers-bestand dat Cloudflare met elke pagina meestuurt. De controle op deze site vraagt het adres dat je invoert op vanaf onze server, volgt maximaal drie omleidingen en leest de headers van de uiteindelijke respons.

De zes belangrijkste headers

Dit zijn de headers die de controle beoordeelt. De getoonde waarden zijn gangbare, veilige uitgangspunten; pas ze aan aan wat je site nodig heeft.

Hoe de controle van IPNixa elke header beoordeelt

Elke header krijgt een van drie statussen: aanwezig, controleren of niet opgegeven. Controleren betekent dat de header bestaat, maar dat de waarde niet voldoet aan de regel hieronder; het is een aanleiding om beter te kijken, geen beveiligingsscore.

• HSTS is aanwezig als de header één keer voorkomt met een max-age van minimaal 15552000 seconden (180 dagen). Een kortere max-age of een max-age van nul krijgt ‘controleren’.
• CSP is aanwezig als het beleid scripts beperkt via script-src of default-src en nergens in het beleid 'unsafe-inline', 'unsafe-eval' of een losse * bevat. Een report-only-beleid staat als niet opgegeven, omdat het niets blokkeert.
• Framing is aanwezig met een frame-ancestors-richtlijn die beperkt is tot 'none', 'self' of exacte adressen, of met X-Frame-Options op DENY of SAMEORIGIN.
• X-Content-Type-Options is alleen aanwezig met de waarde nosniff.
• Referrer-Policy is aanwezig als de laatste waarde no-referrer, same-origin, strict-origin of strict-origin-when-cross-origin is. Browsers gebruiken de laatste waarde die ze begrijpen, dus bij een lijst telt de laatste vermelding.
• Permissions-Policy is aanwezig zodra de header wordt meegestuurd, omdat de juiste lijst met functies van de site afhangt.

Wat echte sites sturen: een steekproef

Op 2 november 2026 vroegen we vijf homepages op met dezelfde user agent als de controle en beoordeelden we de responsen met de regels van IPNixa. Headers veranderen vaak, dus zie dit als een momentopname.

De steekproef lezen: controleren is niet hetzelfde als zwak

Het beleid van GitHub beperkt scripts tot de eigen asset-host en specifieke hashes, en dat is streng. Het krijgt alleen ‘controleren’ omdat style-src 'unsafe-inline' toestaat en de regel overal in het beleid naar dat sleutelwoord zoekt. Inline stijlen zijn een veel kleiner risico dan inline scripts, dus dit is eerder een bewuste afweging dan een gat.

Onze eigen site krijgt om een andere reden ‘controleren’: het beleid bevat alleen frame-ancestors 'none', wat framing blokkeert maar scripts niet beperkt. We tonen het resultaat hier zoals het is.

De homepage van Google stuurt het scriptbeleid als Content-Security-Policy-Report-Only, dat overtredingen meldt zonder ze te blokkeren, en stuurde bij deze respons geen HSTS mee; grote sites kunnen HTTPS op andere manieren afdwingen, zoals via preloadlijsten in browsers. De portal van Wikipedia stuurt een zeer lange HSTS-max-age en verder weinig op die pagina. Niets hiervan zegt of deze sites in het algemeen veilig zijn; het laat zien om welke browserbeveiligingen elke respons vraagt.

Headers toevoegen aan je eigen site

Voeg één header tegelijk toe, laad je site opnieuw en controleer of pagina’s, logins, ingesloten video’s en betaalformulieren nog werken voordat je de volgende toevoegt.

1. Begin met de headers met weinig risico: X-Content-Type-Options: nosniff, Referrer-Policy: strict-origin-when-cross-origin en X-Frame-Options: DENY, tenzij je pagina’s door een andere site in een frame geladen moeten kunnen worden.
2. Voeg HSTS toe met een korte max-age, zoals 300, controleer of elk subdomein via HTTPS werkt en verhoog de waarde dan naar 31536000. Voeg includeSubDomains alleen toe als alle subdomeinen HTTPS ondersteunen.
3. Schrijf een Content-Security-Policy en stuur die eerst als Content-Security-Policy-Report-Only. Verzamel meldingen van overtredingen of kijk in de browserconsole, herstel of sta de legitieme bronnen toe en schakel dan over op de afdwingende header.
4. Voeg een Permissions-Policy toe met de krachtige functies die je niet gebruikt, bijvoorbeeld camera=(), microphone=(), geolocation=().
5. Gebruik op nginx add_header met de vlag always, op Apache Header always set, en bij statische hosting of een CDN het headersbestand of de regels voor responsheaders van het platform.
6. Voer de headercontrole van IPNixa opnieuw uit. Voor elke ontbrekende header toont die een kopieerklare regel voor nginx, Apache of een _headers-bestand.

HSTS-preload en andere aandachtspunten

HSTS-preloadlijsten zijn in browsers ingebouwd, zodat zelfs het allereerste bezoek HTTPS gebruikt. Voor aanmelding van een domein zijn een max-age van minimaal een jaar, includeSubDomains en de preload-richtlijn vereist, en het duurt maanden voordat een verwijdering gebruikers bereikt. Meld je domein alleen aan als elk subdomein, ook interne, op HTTPS blijft.

X-XSS-Protection is verouderd; moderne browsers negeren de header en CSP vervangt hem. De headers voor cross-origin-isolatie (Cross-Origin-Opener-Policy, Cross-Origin-Embedder-Policy en Cross-Origin-Resource-Policy) worden door de controle niet beoordeeld, omdat alleen sites die functies zoals gedeeld geheugen gebruiken ze nodig hebben en ze ingesloten inhoud van derden kunnen blokkeren.