De 7 security headers die er echt toe doen

In het kort

• De meeste “security headers”-lijsten zijn te lang en deels achterhaald. Zeven headers doen het echte werk: HSTS, CSP, X-Content-Type-Options, frame-ancestors (CSP) / X-Frame-Options, Referrer-Policy, Permissions-Policy en Cross-Origin-Opener-Policy.
• Eén “header” die je juist op 0 zet: X-XSS-Protection. Het advies om er 1; mode=block van te maken is verouderd en kan zélf kwetsbaarheden introduceren.
• Hieronder de exacte waarden die cobytes.com op dit moment meestuurt, met per header: wat hij doet, wat wij instellen, en waarom.
• Zet headers op je webserver (nginx), niet in een plugin — dan overleven ze caching en updates.

Waarom de meeste header-lijsten je niet verder helpen

Online vind je lijstjes van vijftien tot twintig “must-have” security headers. Een deel daarvan is verouderd (Public-Key-Pins is dood, Expect-CT is uitgefaseerd), een deel doet niets zonder de juiste waarde, en een enkele kan zelfs kwaad als je ‘m verkeerd zet. Het resultaat: beheerders kopiëren een config die ze niet begrijpen, of geven het op.

We draaien het liever om. Dit zijn de headers die cobytes.com vandaag meestuurde toen je deze pagina opende — en per stuk waaróm.

1. Strict-Transport-Security (HSTS)

strict-transport-security: max-age=31536000; includeSubDomains; preload

HSTS dwingt de browser om je site een jaar lang (max-age=31536000) uitsluitend over HTTPS te benaderen — ook als iemand http:// typt of op een oude link klikt. includeSubDomains trekt dat door naar elk subdomein. preload betekent dat we de site hebben aangemeld op de HSTS-preloadlijst die in Chrome, Firefox en Safari is ingebakken: de allereerste request gaat dan al over HTTPS, nog vóór er ooit contact is geweest. Let op: zet preload pas aan als écht al je subdomeinen HTTPS spreken — anders sluit je ze buiten.

2. Content-Security-Policy (CSP)

content-security-policy: ... script-src 'nonce-<per-request>' 'strict-dynamic'; object-src 'none'; frame-ancestors 'self'; ...

De CSP is de krachtigste en tegelijk lastigste header. Hij bepaalt welke bronnen (scripts, stijlen, frames, afbeeldingen) mogen laden. Goed ingesteld vangt hij XSS af waar alle andere maatregelen falen. Wij draaien een strict script-src met een per-request nonce en 'strict-dynamic' — zonder 'unsafe-inline' of 'unsafe-eval'. Omdat dit de header is die je het makkelijkst je hele site mee sloopt, behandelen we ‘m apart.

→ *Diepte: Onze productie-CSP op WordPress: van unsafe-eval naar strict-dynamic — de exacte policy en hoe we ‘m zonder downtime omzetten.*

3. X-Content-Type-Options

x-content-type-options: nosniff

Eén woord, groot effect. nosniff verbiedt de browser om te “raden” wat voor bestand hij binnenkrijgt. Zonder deze header kan een browser een geüpload .txt– of afbeeldingsbestand alsnog als JavaScript interpreteren en uitvoeren — een klassieke manier om via een upload-functie code binnen te smokkelen. Er is geen reden om dit ooit níét aan te zetten.

4. X-Frame-Options + frame-ancestors

x-frame-options: SAMEORIGIN
content-security-policy: ... frame-ancestors 'self' ...

Beide beschermen tegen clickjacking: een aanvaller die jouw site in een onzichtbare <iframe> laadt en bezoekers ongemerkt op verborgen knoppen laat klikken. X-Frame-Options: SAMEORIGIN is de oude header; frame-ancestors 'self' in de CSP is de moderne opvolger met meer controle. Wij sturen ze allebei: de CSP voor moderne browsers, X-Frame-Options als vangnet voor oudere. Waar ze elkaar overlappen, wint frame-ancestors.

5. Referrer-Policy

referrer-policy: same-origin

Standaard stuurt je browser bij elke uitgaande klik de volledige URL van je vorige pagina mee als “referrer” — inclusief eventuele paden of tokens die je liever niet lekt naar externe sites. same-origin betekent: referrer-informatie alleen meesturen binnen je eigen domein, en niets naar buiten. Wij kiezen daar bewust voor — strenger dan het vaak-aanbevolen strict-origin-when-cross-origin. Het kan externe analytics-attributie iets beperken, maar voor een zakelijke site weegt het niet-lekken van URL’s zwaarder.

6. Permissions-Policy

permissions-policy: geolocation=(), microphone=(), camera=(), payment=(), usb=(), magnetometer=(), gyroscope=(), accelerometer=()

Deze header zet krachtige browser-API’s standaard uit voor je hele site. De lege haakjes () betekenen: niemand mag dit — ook geen ingesloten scripts of frames. Mocht een geïnjecteerd of gecompromitteerd script ooit de camera, microfoon of locatie van een bezoeker proberen aan te spreken, dan blokkeert de browser dat op voorhand. Voor een hosting-/securitysite die geen van die API’s nodig heeft, is alles dichtzetten de juiste keuze.

7. Cross-Origin-Opener-Policy (COOP)

cross-origin-opener-policy: same-origin-allow-popups

COOP isoleert je pagina van vensters die je opent of die jou openen, wat een hele klasse cross-origin-lekken (zoals Spectre-achtige zijkanalen en window.opener-misbruik) afsluit. We kiezen bewust de variant same-origin-allow-popups in plaats van het strengere same-origin, zodat legitieme pop-ups — zoals de cookie-consent en login-/OAuth-flows — blijven werken.

De header die je op 0 zet: X-XSS-Protection

x-xss-protection: 0

Tegenintuïtief, maar correct. De oude XSS-filters van browsers (X-XSS-Protection: 1; mode=block) zijn uitgefaseerd en konden zélf misbruikt worden om delen van een pagina selectief uit te schakelen. Moderne browsers hebben de filter verwijderd; de aanbevolen waarde is daarom expliciet 0 (uit), en je leunt voor XSS-bescherming op je CSP. Wie in 2026 nog 1; mode=block adviseert, werkt met verouderde informatie.

Onze volgorde van aanpak

Veelgestelde vragen

Hoeveel security headers heb ik minimaal nodig? Deze zeven dekken de echte aanvalsklassen: XSS, clickjacking, protocol-downgrade, MIME-sniffing en cross-origin-lekken. Meer headers toevoegen levert vooral een mooiere scanscore op, niet per se meer veiligheid.

Waar zet ik deze headers het beste neer? Op je webserver (nginx/Apache) of via je CDN, niet in een WordPress-plugin. Op de webserver gelden ze voor élke response — ook voor gecachte pagina’s en statische bestanden — en overleven ze plugin-updates.

Hoe controleer ik mijn eigen headers? Stuur je site door securityheaders.com of bekijk de response-headers in de Network-tab van je browser.

Wil je dit goed ingeregeld hebben in plaats van zelf puzzelen? Bij security en managed hosting van Cobytes zetten we deze headers in als onderdeel van de standaard hardening — getest, op de webserver, en zonder je site te slopen. Begin bij onze pillar over website hardening.