Elk antwoord van een webserver begint met headers die de bezoeker niet ziet: inhoudstype, cache, cookies. Sommige daarvan dienen alleen de beveiliging. Ze verhelpen geen enkel lek in de site, maar vragen de browser riskant gedrag te weigeren: de pagina tonen in het frame van een andere site, het type van een bestand raden, een onbekend script laden of terugvallen op HTTP. De bescherming geldt dus voor de bezoekers en voor de manier waarop je pagina's bij hen worden weergegeven.
De belangrijkste beveiligingsheaders
| Header | Functie | Gangbare waarde |
|---|---|---|
Strict-Transport-Security | Dwingt HTTPS af bij volgende bezoeken | max-age=31536000 |
Content-Security-Policy | Somt de toegestane bronnen voor scripts, stijlen en frames op | Per site op te bouwen |
X-Frame-Options | Verbiedt weergave in een extern frame | SAMEORIGIN of DENY |
X-Content-Type-Options | Verbiedt de browser het type van een bestand te raden | nosniff |
Referrer-Policy | Beperkt het adres dat aan gelinkte sites wordt doorgegeven | strict-origin-when-cross-origin |
Permissions-Policy | Schakelt gevoelige browser-API's uit | camera=(), microphone=(), geolocation=() |
Twee ervan verdienen een eigen definitie: HSTS, dat HTTPS vastzet, en de Content Security Policy, de doeltreffendste header tegen een XSS-lek maar ook de lastigste om goed in te stellen. X-Frame-Options en de CSP-directive frame-ancestors beschermen tegen clickjacking.

Headers die je niet meer verstuurt
De OWASP-cheatsheet over HTTP-headers raadt X-XSS-Protection af, omdat die lekken kan veroorzaken op sites die in orde zijn (weglaten of op 0 zetten), en ook Expect-CT, die je moet verwijderen. Feature-Policy is vervangen door Permissions-Policy. Omgekeerd raadt OWASP aan X-Powered-By te verwijderen en Server zo weinig mogelijk te laten vertellen: die headers verraden de versie van PHP of van de server en maken fingerprinting makkelijker.
Voor WordPress
WordPress verstuurt al X-Frame-Options: SAMEORIGIN en frame-ancestors 'self' in de beheeromgeving en op de inlogpagina, via de functie send_frame_options_header(). De openbare pagina's krijgen standaard geen van deze headers. Je kunt ze op drie plekken toevoegen:
- De server:
Header always setin een.htaccessonder Apache of LiteSpeed,add_header ... alwaysin Nginx. Dat is de volledigste oplossing, omdat die ook statische bestanden en gecachete pagina's dekt. - Het CDN: regels die het antwoord aanpassen, handig als de site achter een proxy staat.
- PHP of een plugin: de action
send_headers, nuttig zonder toegang tot de configuratie, maar afwezig in antwoorden die niet via WordPress lopen.
Controleer het resultaat daarna met curl -I https://jouw-site.nl/ of het tabblad Netwerk van de browser, nadat je de caches hebt geleegd. Onze gids over HTTP-beveiligingsheaders voor WordPress geeft startwaarden en configuratievoorbeelden; het artikel over wat Google meeweegt zet hun (kleine) rol in SEO op een rij.
Veelgemaakte fouten
- Een header op twee plekken toevoegen (server en plugin) met verschillende waarden.
alwaysvergeten: zonder die toevoeging zetten Apache en Nginx de header niet op foutpagina's.- Een perfecte score op een auditprogramma nastreven met een strikte CSP die de editor of de betaling breekt.
In WP Masquerade verstuurt de gratis versie nosniff vanaf het eerste niveau van de module Hardening, en beheert de Pro-versie de beveiligingsheaders vanuit de beheeromgeving, met een knop die de werkelijk ontvangen headers toont. Een pagina die door een cache ervoor wordt geserveerd, kan ze echter missen: voor een strikt beleid blijft de serverconfiguratie het veiligst.