Security headers: welke heeft uw website nodig?

Elke keer dat een browser een pagina opvraagt, stuurt de server naast de HTML ook een set headers mee: korte regels met instructies. Een deel daarvan gaat over veiligheid. Ze bepalen bijvoorbeeld of de browser de site ooit nog via onversleuteld HTTP mag benaderen, welke scripts er mogen draaien, en of andere sites uw pagina's in een frame mogen insluiten.

Het bijzondere is dat de bescherming bij de bezoeker plaatsvindt. Zelfs als een aanvaller erin slaagt kwaadaardige code op uw pagina te krijgen, kan een goed ingestelde browser die code weigeren uit te voeren. Headers zijn daarmee een vangnet voor fouten die elders in de site zitten: een vergeten inputfilter, een verouderde plugin, een injectie via een commentaarveld.

Ze vervangen geen veilig ontwikkelproces. Ze vullen het aan. Een site zonder HTTPS en zonder headers scoort laag op elke serieuze veiligheidsmeting, hoe netjes de rest van de code ook is. Omgekeerd: met een geldig SSL-certificaat én de juiste headers legt u de basis waarop de rest van de pijler veiligheid rust.

Zes headers dekken samen het grootste deel van de risico's af. Deze controleert de WebYes-scan binnen de pijler veiligheid:

HSTS verdient een korte toelichting naast de tabel. Volgens de MDN-documentatie over Strict-Transport-Security onthoudt de browser na de eerste HTTPS-hit dat uw site uitsluitend via HTTPS benaderd mag worden. Zonder HSTS blijft er bij elk getypt adres een onversleuteld verzoek mogelijk, tot de redirect ingrijpt.

De Content-Security-Policy verdient aparte aandacht. Deze header bepaalt per brontype (scripts, stijlen, afbeeldingen, frames) welke domeinen zijn toegestaan. Een strikte CSP maakt cross-site scripting vrijwel onmogelijk, omdat de browser scripts van niet-toegestane bronnen simpelweg niet uitvoert.

Diezelfde kracht maakt CSP ook de header die het vaakst iets breekt. Een vergeten domein voor uw statistieken-script of embedded video, en dat onderdeel doet het niet meer. Begin daarom altijd met Content-Security-Policy-Report-Only: de browser rapporteert dan overtredingen zonder iets te blokkeren, zodat u de policy kunt aanscherpen voordat hij echt afdwingt.

Een praktische volgorde: inventariseer alle externe scripts en CDN's die uw site laadt, schrijf een report-only policy, bekijk een week lang de rapporten, en schakel pas daarna over naar een afdwingende CSP. Wie in één keer een strikte policy live zet, merkt meestal pas via klachten dat de chatwidget of de betaalknop stilstaat. Voor directives, unsafe-inline en de WebYes-checks leest u de aparte pagina over Content Security Policy.

Waar u headers instelt, hangt af van uw opzet: in de serverconfiguratie (Apache, nginx), bij uw CDN of hostingpakket, of in uw framework (bijvoorbeeld next.config of response middleware). Voor de meeste sites is het een kwestie van een paar regels configuratie die u eenmalig toevoegt en daarna met rust laat, met CSP als uitzondering die onderhoud vraagt bij elke nieuwe externe dienst.

Controleren kan zonder diepe technische kennis. De gratis WebYes-scan toetst de headers van uw site binnen de pijler veiligheid en laat per ontbrekende header zien wat het risico is. Voor het WebYes-keurmerk moet het gemiddelde over alle pijlers minstens 80 zijn, én elke pijler (inclusief veiligheid) minstens 60. Ontbrekende headers zijn een van de snelste manieren om onder die vloer van 60 te zakken.

Naast WebYes is de Internet.nl-test nuttig voor een bredere blik op moderne internetstandaarden, inclusief HTTPS en gerelateerde serverinstellingen. In onze gids over de Internet.nl-test leest u hoe die meting zich verhoudt tot een productscan. Gebruik WebYes voor diagnose en herstelrichting; gebruik Internet.nl als onafhankelijke referentie wanneer u dieper wilt gaan.

De meest voorkomende misser is HSTS zonder werkende HTTPS-redirect, of omgekeerd: wel een redirect, maar geen HSTS. Beide horen bij elkaar. Een andere klassieker: X-Frame-Options op DENY zetten terwijl u zelf een preview of admin-frame nodig heeft, zonder frame-ancestors in CSP als modern alternatief te overwegen.

Ook zien we sites die Permissions-Policy helemaal weglaten, of juist zo strak zetten dat legitieme features (een kaart met geolocatie, een upload met camera) stilvallen. Begin bij wat u echt gebruikt: blokkeer camera, microfoon en geolocation als uw site die nooit nodig heeft.

Tot slot: headers op de homepage en niet op de rest van de site. Een CDN of reverse proxy die alleen de root path configureert, laat diepe pagina's onbeschermd. Controleer na elke wijziging een paar willekeurige URL's, niet alleen de homepage. De gratis WebYes-scan (bèta) dekt maximaal zes pagina's; een betaalde full audit loopt tot vijftien pagina's sitemap-geleid en toont de steekproef in het rapport.

Zakt de veiligheidspijler onder 60, begin bij HTTPS plus HSTS. Zonder versleutelde verbinding en browser-force naar HTTPS blijven andere headers een pleister. Daarna X-Content-Type-Options (nosniff) en Referrer-Policy: laag risico, snelle winst. Frame-bescherming (CSP frame-ancestors of X-Frame-Options) volgt als u embeds en clickjacking-risico meeneemt. Controleer na elke header ook een diepe URL, niet alleen de homepage.

CSP komt als laatste in de prioriteitslijst, niet omdat het onbelangrijk is, maar omdat het onderhoud kost. Zet eerst report-only aan, inventariseer third parties, en forceer pas daarna. Zo voorkomt u dat u de keurmerkvloer haalt op headers en tegelijk de checkout breekt. Herhaal de WebYes-scan na elke stap; gemiddelde ≥80 en elke pijler ≥60 blijven de harde lat.