Security headers voor WordPress: complete gids

Security headers voor WordPress zijn HTTP-responseheaders die de browser regels geven voor onder meer HTTPS, scripts, iframes en het delen van verwijzende URL-informatie. Ze vormen een waardevolle extra beveiligingslaag, maar zijn geen vervanging voor updates, veilige inlogbeveiliging, back-ups of betrouwbare hosting. Begin met het inventariseren van je huidige headers, voer wijzigingen gefaseerd door en test altijd formulieren, analytics, embeds en andere externe diensten.

Wat zijn security headers?

Wanneer iemand een pagina van je WordPress-site opent, stuurt de webserver naast HTML ook HTTP-headers mee. Security headers beperken bepaalde browserrisico's. Ze kunnen bijvoorbeeld afdwingen dat een browser HTTPS gebruikt, voorkomen dat pagina's ongewenst in een iframe laden of regelen vanaf welke bronnen scripts mogen komen.

De headers werken in de browser van de bezoeker. Daardoor zijn ze een aanvulling op beveiliging op de server en in WordPress zelf. Een goed ingestelde header lost dus geen verouderde plugin, zwak wachtwoord of kwetsbaar thema op. Zie headers als één onderdeel van structureel technisch beheer.

Welke security headers zijn relevant voor WordPress?

Header	Wat beperkt deze?	Praktische keuze voor een WordPress-site	Let hierop
Strict-Transport-Security	Gebruik van een onbeveiligde HTTP-verbinding nadat de browser de regel kent.	Overweeg dit alleen wanneer de hele website en relevante subdomeinen correct via HTTPS werken.	Een fout certificaat, onjuist subdomein of onvolledige HTTPS-migratie kan bezoekers buitensluiten.
Content-Security-Policy	Het laden en uitvoeren van ongewenste scripts, stijlen, afbeeldingen, frames en andere bronnen.	Start met Content-Security-Policy-Report-Only en inventariseer eerst alle benodigde externe bronnen.	Een te strenge policy kan formulieren, meetcodes, video-embeds, kaarten en betaalmodules verstoren.
X-Content-Type-Options	Ongewenst interpreteren van bestanden als een ander contenttype.	Gebruik de instelling nosniff als je server en bestanden correct zijn geconfigureerd.	Test vooral gedownloade bestanden en specifieke scripts of stylesheets na invoering.
Referrer-Policy	Het onnodig doorgeven van volledige URL-informatie aan andere websites.	Kies een beleid dat privacy beschermt zonder noodzakelijke meet- of betaalstromen te verstoren.	Controleer koppelingen met externe platforms die verwijzingsinformatie gebruiken.
Permissions-Policy	Onnodige toegang van pagina's of embeds tot browserfuncties, zoals camera, microfoon of locatie.	Sta alleen functies toe die je site werkelijk gebruikt.	Embeds van externe partijen kunnen andere browserrechten nodig hebben dan je verwacht.
X-Frame-Options	Het ongewenst laden van je pagina in een iframe, een risico bij clickjacking.	Blokkeer framing als je site niet door een extern portaal in een iframe hoeft te staan.	Gebruik dit niet blind wanneer een klantportaal, partneromgeving of embed je pagina moet tonen.
Cross-Origin-Opener-Policy en Cross-Origin-Resource-Policy	Onbedoelde interacties en het delen van resources tussen verschillende origins.	Beoordeel deze alleen wanneer je begrijpt welke externe resources en integraties je site gebruikt.	Deze headers kunnen complexe gevolgen hebben voor externe tools en embeds.

Headers die je niet blind moet instellen

Niet elke header die je in oude handleidingen ziet, is nog een goede keuze. OWASP benoemt onder meer X-XSS-Protection, Expect-CT en HTTP Public Key Pinning als verouderd of niet aanbevolen voor nieuwe implementaties. Voeg zulke headers niet toe omdat een scanner ze noemt. Controleer altijd de actuele aanbeveling en het verwachte browsergedrag.

Ook moderne headers kunnen schadelijk zijn wanneer ze zonder context worden gekopieerd. Vooral een harde Content Security Policy, HSTS met een ondoordachte scope en cross-originheaders vragen om kennis van je hosting, domeinen, CDN en externe diensten.

Security headers voor WordPress instellen: stappenplan

1. Breng je technische landschap in kaart. Noteer je hoofddomein, eventuele subdomeinen, hostingpartij, CDN, cachinglaag en alle externe diensten. Denk aan formulierdiensten, analytics, tagmanagement, chat, video, kaarten, betaalproviders en ingesloten agenda's.
2. Controleer de huidige responseheaders. Open een belangrijke pagina in de browser, ga naar de ontwikkelaarstools en bekijk bij Network of Netwerk de responseheaders van het HTML-document. Controleer niet alleen de homepage, maar ook een dienstenpagina, blogartikel, formulierpagina en inlogomgeving.
3. Kies de implementatielaag. Stel headers bij voorkeur in op de plek die alle relevante HTML-responses bereikt: de webserver, hostingomgeving of CDN. Een WordPress-plugin kan bruikbaar zijn wanneer je geen toegang hebt tot die lagen, maar controleer dan of caching en andere configuraties de header niet overschrijven.
4. Begin met laag-risicoheaders. Beoordeel eerst headers zoals X-Content-Type-Options, Referrer-Policy, Permissions-Policy en, waar passend, X-Frame-Options. Maak per header een keuze die past bij de functies die je website daadwerkelijk aanbiedt.
5. Voer CSP eerst in report-only-modus in. Met Content-Security-Policy-Report-Only kun je overtredingen signaleren zonder bronnen direct te blokkeren. Gebruik de uitkomsten om toegestane bronnen bewust te bepalen. Voeg niet ruimhartig complete domeinen of onveilige uitzonderingen toe om meldingen snel te laten verdwijnen.
6. Activeer HSTS pas na een volledige HTTPS-controle. Bevestig dat HTTPS op alle relevante pagina's en subdomeinen werkt, certificaten geldig zijn en er geen mixed content overblijft. Bouw de inzet vervolgens zorgvuldig op.
7. Test kernhandelingen na iedere wijziging. Verstuur formulieren, test conversiemetingen, laad video en kaart-embeds, doorloop eventuele betaal- of afspraakprocessen en controleer de mobiele weergave. Test ook ingelogde functionaliteit als medewerkers of klanten die gebruiken.
8. Leg de keuzes vast en herhaal controles. Noteer waar headers worden beheerd, welke uitzonderingen bewust zijn gemaakt en welke externe diensten afhankelijk zijn van die keuzes. Controleer de configuratie opnieuw na een nieuw thema, plugin, CDN-wijziging of marketingintegratie.

CSP veilig invoeren zonder je website te breken

Content Security Policy is vaak de krachtigste, maar ook de meest gevoelige header. CSP bepaalt welke bronnen een pagina mag laden. Dat kan de impact van bepaalde scriptinjecties beperken, maar WordPress-sites gebruiken regelmatig scripts van thema's, plugins en externe diensten.

Begin daarom niet met een kant-en-klare, afdwingende policy van een andere site. Gebruik eerst report-only. Bekijk vervolgens welke bronnen worden gemeld op de pagina's die ertoe doen. Neem daarbij ook cookiebeheer, meettools, YouTube of Vimeo, kaarten, lettertypen, formulieren en advertentiescripts mee. Pas wanneer de benodigde bronnen helder zijn en de belangrijkste processen goed werken, kun je beoordelen of een afdwingende CSP verantwoord is.

Een CSP is geen eenmalige instelling. Een nieuwe plugin of campagne kan nieuwe scripts introduceren. Neem CSP-controle daarom op in je wijzigingsproces en technische onderhoud.

Hoe controleer je security headers?

Een externe scanner kan nuttig zijn om ontbrekende of afwijkende headers te signaleren. Zie de uitkomst echter als startpunt voor onderzoek, niet als eindbeoordeling. Een score vertelt niet of een header past bij jouw formulieren, integraties en bedrijfsproces.

• Controleer responseheaders in de browserontwikkelaarstools.
• Vergelijk de homepage met belangrijke landingspagina's, blogartikelen en formulierpagina's.
• Controleer of HTTP consequent naar HTTPS leidt voordat je HSTS inzet.
• Test na elke configuratiewijziging de belangrijkste conversiepaden.
• Controleer of je CDN, cacheplugin of hostinglaag headers wijzigt, verwijdert of dubbel meestuurt.

Test ook foutenpagina's en redirects. Een correcte technische configuratie voorkomt niet automatisch inhoudelijke of SEO-technische problemen met foutpagina's. Lees daarom ook onze gids over 404- en soft-404-fouten.

Veelgemaakte fouten

• Headers alleen op de homepage plaatsen. Een header moet beschikbaar zijn op alle relevante responses, niet alleen op één template.
• Een CSP direct afdwingen. Daardoor kunnen essentiële scripts of embeds onverwacht stoppen met werken.
• Dubbele of strijdige headers versturen. Dit gebeurt bijvoorbeeld wanneer zowel een CDN, hostingomgeving als plugin instellingen toevoegt.
• HSTS activeren voordat HTTPS overal klopt. Controleer domeinen, subdomeinen, certificaten en redirects vooraf zorgvuldig.
• Blind een scanner-score najagen. De beste configuratie is een werkende, onderbouwde configuratie die past bij je site, niet een willekeurige maximale score.
• Headers als volledige beveiligingsstrategie behandelen. Updates, toegangsbeheer, betrouwbare plugins en herstelbare back-ups blijven noodzakelijk.

Security headers zijn onderdeel van WordPress-beheer

Security headers beschermen niet tegen alle risico's. Houd WordPress core, thema's en plugins actueel, beperk beheerdersrechten, bescherm inloggen en zorg voor gecontroleerde back-ups. Raadpleeg ook onze praktische gids over back-ups voor WordPress voor het voorbereiden en testen van herstel.

Voor nieuwe websites is het verstandig om security headers al mee te nemen in de technische oplevering. Bij strategisch en creatief webdesign horen techniek, gebruiksgemak en een onderhoudbare basis bij elkaar. Bekijk ook alle diensten van LYNX Media als je website, vindbaarheid en conversie als één geheel wilt verbeteren.

Praktische checklist

• Ik weet waar responseheaders worden ingesteld: server, hosting, CDN of plugin.
• Ik heb headers gecontroleerd op meerdere belangrijke paginatypen.
• Ik heb alle externe scripts, embeds en formulier- of betaalintegraties geïnventariseerd.
• Ik voer CSP eerst in report-only-modus in.
• Ik activeer HSTS alleen na een volledige HTTPS- en certificaatcontrole.
• Ik test formulieren, metingen, embeds en ingelogde functies na elke wijziging.
• Ik voorkom dubbele configuratie tussen CDN, hosting en WordPress.
• Ik controleer headers opnieuw na technische wijzigingen en periodiek onderhoud.

Wanneer schakel je hulp in?

Laat de configuratie controleren wanneer je website afhankelijk is van complexe tracking, betaalstromen, klantportalen, meerdere subdomeinen of veel externe embeds. Ook als een CSP meldingen oplevert die je niet kunt duiden, is het verstandig niet op goed geluk uitzonderingen toe te voegen. Bespreek je website of online groeikansen met LYNX Media als je technische keuzes wilt laten beoordelen in samenhang met prestaties, SEO en conversie.