Security Headers uitgelegd: HSTS, CSP en X-Frame voor je website
Ontdek welke security headers je website nodig heeft. Praktische uitleg van HSTS, CSP, X-Frame en de impact op je SEO en bezoekers.
Wat zijn security headers?
Security headers zijn instructies die je webserver meestuurt met elke pagina-aanvraag. Ze vertellen de browser hoe deze moet omgaan met de inhoud van je site, welke verbindingen veilig zijn en welke acties wel of niet toegestaan zijn. Deze headers beschermen je bezoekers tegen veelvoorkomende aanvallen zoals clickjacking, cross-site scripting en man-in-the-middle aanvallen. Voor MKB-websites zijn ze essentieel, niet alleen voor veiligheid maar ook voor vertrouwen en rankings.
Google heeft de afgelopen jaren steeds meer signalen rondom websiteveiligheid meegenomen in rankingbeslissingen. Een site zonder basis security headers oogt amateuristisch in audits, scoort lager bij security scans en kan in extreme gevallen waarschuwingen krijgen in Chrome of Edge.
Het mooie aan security headers: ze kosten niets, ze werken direct na implementatie, en je hoeft er na correcte instelling niet meer naar om te kijken. Toch zie ik bij de meeste MKB-sites dat ze of helemaal ontbreken of half geconfigureerd zijn.
De belangrijkste security headers in een overzicht
| Header | Beschermt tegen | Prioriteit |
|---|---|---|
| HSTS (Strict-Transport-Security) | Downgrade aanvallen, HTTP-onderschepping | Hoog |
| CSP (Content-Security-Policy) | Cross-site scripting (XSS) | Hoog |
| X-Frame-Options | Clickjacking | Hoog |
| X-Content-Type-Options | MIME-sniffing aanvallen | Middel |
| Referrer-Policy | Lekken van referrer info | Middel |
| Permissions-Policy | Ongewenste browser API toegang | Middel |
HSTS: dwing HTTPS af voor alle bezoekers
HTTP Strict Transport Security (HSTS) is de belangrijkste security header die je kunt instellen. Hij vertelt de browser: “Bezoek deze site nooit meer via HTTP, altijd via HTTPS.” Zelfs als een gebruiker http typt, schakelt de browser direct over.
Waarom dit belangrijk is: zonder HSTS kan een aanvaller in een onveilig wifi netwerk de eerste HTTP-aanvraag onderscheppen en je site vervangen door een nepversie. HSTS voorkomt dit door de browser te dwingen direct HTTPS te gebruiken.
De juiste HSTS configuratie
Een goede HSTS header heeft drie onderdelen: max-age (hoe lang de browser deze regel onthoudt), includeSubDomains (of de regel ook geldt voor subdomeinen) en preload (of je site in de officiele preload-lijst van browsers wilt). Voor productie raad ik aan: max-age van minimaal 1 jaar, includeSubDomains aan, en preload alleen als je echt zeker weet dat alle subdomeinen HTTPS ondersteunen.
Let op: HSTS is moeilijk terug te draaien. Als je de header instelt en daarna je certificaat vervalt, kunnen bezoekers je site niet meer bereiken. Test grondig voor productie.
Content Security Policy: je sterkste wapen tegen XSS
Content Security Policy (CSP) is de meest krachtige maar ook de meest complexe security header. Hij definieert precies welke bronnen (scripts, stijlen, afbeeldingen, fonts) je site mag laden. Alles wat niet expliciet is toegestaan, wordt geblokkeerd.
Voorbeeld: je CSP zegt dat scripts alleen mogen komen van je eigen domein en van Google Analytics. Een aanvaller die malicious JavaScript probeert te injecteren via een formulierveld, krijgt het script geblokkeerd door de browser. De aanval mislukt.
CSP stapsgewijs invoeren
De grootste fout bij CSP: meteen een strikte policy live zetten. Het resultaat: je hele site breekt omdat je Google Maps, YouTube embeds of Hotjar tracking blokkeert. Begin altijd met de Content-Security-Policy-Report-Only header. Deze meldt overtredingen zonder iets te blokkeren. Na enkele weken monitoren weet je precies welke bronnen je nodig hebt, en kun je veilig overschakelen naar de echte CSP header.
Voor WordPress sites bestaan plugins die helpen met CSP-generatie, maar wees voorzichtig: een verkeerd geconfigureerde CSP kan je site stuk maken in browsers die strikt zijn over de regels.
X-Frame-Options: bescherming tegen clickjacking
Clickjacking is een aanval waarbij een aanvaller jouw website in een onzichtbaar iframe laadt op zijn eigen site. De bezoeker denkt op de aanvallersite te klikken, maar klikt eigenlijk op jouw site. Dit kan worden misbruikt om gebruikers ongemerkt op koopknoppen of “verstuur” knoppen te laten klikken.
X-Frame-Options heeft drie waarden: DENY (niemand mag jouw site in een iframe laden), SAMEORIGIN (alleen jij mag jouw eigen site in een iframe laden) en ALLOW-FROM (alleen specifieke andere sites mogen het). Voor de meeste MKB-sites is SAMEORIGIN de juiste keuze.
Modernere browsers gebruiken inmiddels frame-ancestors in CSP voor dezelfde bescherming. Een goede setup heeft beide voor maximale compatibiliteit met oudere browsers.
De minder bekende maar belangrijke headers
Naast de drie hoofdrolspelers zijn er nog enkele headers die je veiligheid significant verhogen.
X-Content-Type-Options
Deze header met de waarde nosniff voorkomt dat browsers proberen te raden welk bestandstype een bestand heeft. Zonder deze header kan een aanvaller een afbeelding uploaden die eigenlijk JavaScript bevat. De browser ziet de .jpg extensie, “ruikt” dat het JavaScript is, en voert het uit. Met nosniff gebeurt dit niet meer.
Referrer-Policy
Standaard sturen browsers in de Referer header informatie mee over de pagina vanwaar je komt. Dit kan gevoelig zijn: als iemand vanaf jouw login-pagina ergens heen klikt, lekt de URL van die pagina (mogelijk met tokens). Referrer-Policy met waarde strict-origin-when-cross-origin geeft een goede balans tussen functionaliteit en privacy.
Permissions-Policy
Vroeger Feature-Policy genoemd, controleert deze header welke browser-functies je site mag gebruiken. Heeft jouw zakelijke website toegang tot de camera nodig? Geolocatie? Microfoon? Waarschijnlijk niet. Permissions-Policy laat je expliciet alleen toestaan wat je nodig hebt.
Security headers en SEO: de verbinding
Direct gezien zijn security headers geen rankingfactor in Google’s algoritme. Maar indirect leveren ze meetbare voordelen op. Sites met goede beveiliging hebben minder downtime, beter ingerichte vertrouwenssignalen en betere scores in technische audits.
Belangrijker: tools zoals Lighthouse en PageSpeed Insights nemen security headers mee in hun overall score. Een hoge Lighthouse score wordt door veel bureaus als kwaliteitssignaal gebruikt. Daarnaast kunnen browsers in de toekomst meer waarschuwingen tonen bij sites zonder basis beveiliging, wat je bouncepercentage kan beinvloeden.
Voor sites in gevoelige sectoren (zorg, financieel, juridisch) is goede security al jaren een onuitgesproken eis. E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) bevat een trust component die mede wordt beoordeeld op technische degelijkheid.
Praktijkvoorbeeld: financieel adviesbureau
Een fictief financieel adviesbureau met 12 medewerkers had een nieuwe website laten bouwen. Bij een onafhankelijke security scan kreeg de site een D-rating. De ontwikkelaar had HTTPS geregeld maar geen enkele andere security header geconfigureerd.
De impact was niet direct zichtbaar, maar bij een prospect-pitch bracht een potentiele klant de security scan ter sprake. “Als jullie je eigen website niet veilig krijgen, hoe vertrouwen we jullie advies?” De deal ging niet door.
Na implementatie van HSTS, CSP, X-Frame-Options, X-Content-Type-Options en Referrer-Policy ging de scan-rating naar A+. De Lighthouse Best Practices score steeg van 71 naar 100. In de daaropvolgende maanden werd de A+ rating actief gebruikt in salesgesprekken als bewijs van technische zorgvuldigheid.
De bredere impact: 3 nieuwe klanten gaven aan dat de degelijke technische uitstraling van de website mede de keuze had bepaald. Voor een adviespraktijk met klantwaardes boven 5.000 euro per traject was de investering in security headers ruim terugverdiend.
Veelgemaakte fouten met security headers
- HSTS instellen met te korte max-age waardoor de bescherming nauwelijks effect heeft.
- HSTS preload activeren zonder grondige test, waarna een vervallen certificaat de hele site onbereikbaar maakt.
- CSP direct in productie zetten zonder eerst report-only fase, met als gevolg een gebroken site.
- CSP zo strikt maken dat legitieme tools zoals Google Analytics of YouTube embeds niet meer werken.
- X-Frame-Options vergeten waardoor je site vatbaar blijft voor clickjacking.
- Vertrouwen op alleen X-Frame-Options zonder de modernere CSP frame-ancestors directive.
- Geen monitoring instellen voor CSP-violations, waardoor je nooit weet wat er gebeurt.
- Security headers handmatig in PHP code zetten en vergeten bij een theme-update.
- Dezelfde header twee keer instellen (een in webserver, een in CMS) wat tot conflicten leidt.
- Vergeten dat security headers ook op subdomeinen en API endpoints nodig zijn.
Veelgestelde vragen over security headers
Maken security headers mijn site langzamer?
Nee, security headers zijn enkele extra regels tekst in de HTTP-respons en hebben verwaarloosbare impact op snelheid. De browser verwerkt ze in milliseconden. Het is een van de gratiest beschikbare beveiligingswinsten.
Welke header moet ik als eerste toevoegen?
Begin met X-Frame-Options en X-Content-Type-Options. Deze zijn simpel, kunnen geen schade aan een werkende site veroorzaken en geven directe bescherming. Daarna HSTS na grondige HTTPS controle, en als laatste CSP via een geleidelijke rollout.
Hoe controleer ik welke headers mijn site al heeft?
Gebruik gratis tools zoals SecurityHeaders.com of Mozilla Observatory. Deze geven een rapportcijfer en concrete aanbevelingen. In je browser kun je via Developer Tools tab Network bij elk verzoek de response headers bekijken.
Werken security headers ook bij WordPress?
Ja, je kunt ze instellen via je .htaccess bestand (Apache), nginx configuratie of via plugins zoals Really Simple SSL of HTTP Headers. Plugins zijn handig voor beginners, directe serverconfiguratie geeft meer controle voor gevorderde gebruikers.
Wat is het verschil tussen HSTS en gewoon HTTPS?
HTTPS versleutelt het verkeer als de browser verbinding maakt via HTTPS. HSTS dwingt de browser om altijd HTTPS te gebruiken, zelfs als de gebruiker http typt. Zonder HSTS is de eerste verbinding kwetsbaar voor onderschepping.
Kan ik CSP gebruiken als ik veel externe scripts heb?
Ja, maar wel met meer werk. Je moet alle vertrouwde bronnen expliciet whitelisten. Voor sites met veel tracking, embeds en third-party widgets is dit complex. Het report-only mechanisme helpt om alle gebruikte bronnen te ontdekken voordat je blokkeert.
Welke header voorkomt SQL-injectie?
Geen enkele. SQL-injectie wordt voorkomen in je server-side code door geparametriseerde queries en input-validatie. Security headers beschermen de browser-kant. Je hebt beide nodig: veilige headers en veilige backend code.
Verlies ik mijn rankings als ik mijn security headers verkeerd instel?
Niet direct, maar een gebroken site door verkeerde CSP of HSTS kan tot dalingen leiden door slechte gebruikerservaring. Test altijd in een staging-omgeving of tijdens daluren, en monitor je site direct na elke wijziging.
Aan de slag met security headers
Security headers implementeren is een van de meest waardevolle technische verbeteringen die je in een uur kunt regelen. De combinatie van directe veiligheidswinst, betere audit-scores en geen kosten maakt het een no-brainer voor elke serieuze website.
Wil je weten welke security headers jouw site nu heeft en welke je nog mist? Plan een vrijblijvend strategiegesprek en we kijken samen naar je technische SEO-fundament inclusief security.
Gerelateerde artikelen:
