Security Headers

Security headers zijn HTTP-antwoordheaders die je webserver meestuurt naar de browser van een bezoeker. Ze bevatten instructies over hoe de browser met je website-inhoud moet omgaan om aanvallen zoals cross-site scripting (XSS), clickjacking en man-in-the-middle-aanvallen te voorkomen. In de praktijk werken ze als een set beveiligingsregels die je activeert op serverniveau, zonder dat je je website-code hoeft aan te passen. Voor MKB-bedrijven met een webshop, klantportaal of WordPress-site zijn security headers een van de meest effectieve en laagdrempelige manieren om de beveiliging te verhogen.

Hoe security headers werken op technisch niveau

Elke keer dat een browser een pagina van je website opvraagt, stuurt je webserver een HTTP-respons terug. Die respons bestaat uit de zichtbare inhoud (HTML, CSS, afbeeldingen) plus een reeks headers met metadata. Security headers zijn specifieke instructies binnen die metadata. Een header als Content-Security-Policy vertelt de browser bijvoorbeeld welke scripts, afbeeldingen en stylesheets hij wel of niet mag laden. X-Frame-Options blokkeert het inladen van je site in een iframe op een andere website, waardoor clickjacking wordt voorkomen. Strict-Transport-Security dwingt HTTPS af, zelfs als een gebruiker per ongeluk een HTTP-link volgt. Deze headers worden geïnterpreteerd door moderne browsers en werken dus zonder dat bezoekers er iets van merken.

Waarom security headers ontstonden en waarom ze nu cruciaal zijn

Security headers zijn vanaf begin jaren 2000 ontwikkeld als reactie op grootschalige aanvallen waarbij kwaadwillenden misbruik maakten van de manier waarop browsers met externe content omgaan. Cross-site scripting, waarbij aanvallers scripts in je site injecteren, was een van de meest voorkomende kwetsbaarheden. Browsers voerden aanvankelijk alle code uit die ze tegenkwamen, zonder kritisch te kijken naar de bron. Met de introductie van headers zoals Content-Security-Policy en X-XSS-Protection kregen website-eigenaren voor het eerst de mogelijkheid om die standaardgedrag te beperken. Volgens de W3C Content Security Policy Level 3-specificatie zijn deze headers nu onderdeel van de webstandaard. In de praktijk zien we dat websites zonder security headers kwetsbaarder zijn voor datadiefstal, phishing en reputatieschade.

Wat security headers opleveren voor MKB-bedrijven

Voor een Nederlandse webshop of dienstverlener met een klantportaal betekenen security headers een directe verlaging van het risico op datalekken en aanvallen. Een webshop die persoonsgegevens en betaalgegevens verwerkt, moet voldoen aan de AVG-verplichtingen rond beveiliging. Security headers zijn een van de technische maatregelen die je kunt aantonen bij een audit. Daarnaast waarderen zoekmachines zoals Google sites met een sterke beveiligingsconfiguratie hoger, omdat ze veiliger zijn voor gebruikers. Bij een goed geconfigureerde WordPress hosting-omgeving worden security headers standaard ingesteld op serverniveau, waardoor je als ondernemer niet zelf met .htaccess-bestanden hoeft te werken. Het resultaat is een site die beter beschermd is tegen aanvallen, zonder dat je snelheid of gebruiksvriendelijkheid inlevert.

Security headers zijn niet alleen voor grote platforms of banken. Ook een MKB-webshop met 500 producten of een B2B-dienstverlener met een klantportaal profiteert direct van deze techniek. Hieronder lees je waar je security headers in de praktijk inzet en welke headers het meest relevant zijn voor Nederlandse bedrijven.

Bescherming tegen cross-site scripting in webshops en formulieren

Cross-site scripting (XSS) is een aanval waarbij een hacker kwaadaardige scripts in je website injecteert, bijvoorbeeld via een niet-goed-beveiligd contactformulier of productreview-veld. Die scripts kunnen inloggegevens stelen of bezoekers doorsturen naar phishing-pagina's. De header Content-Security-Policy (CSP) voorkomt dit door de browser te vertellen welke scripts hij mag uitvoeren. Je kunt bijvoorbeeld instellen dat alleen scripts van je eigen domein en van Google Analytics mogen draaien. Voor een webshop op WooCommerce of Shopify betekent dit dat je formulieren en checkout-flows beter beschermd zijn. In de praktijk merken we bij webshop-ontwikkeltrajecten dat een strikte CSP soms conflicteert met externe plugins of tracking-scripts. Daarom stel je CSP in report-only-modus in tijdens de testfase, zodat je ziet welke scripts geblokkeerd worden zonder dat je site kapot gaat.

Voorkomen van clickjacking bij klantportalen en inlogpagina's

Clickjacking is een aanvalstechniek waarbij een hacker je inlogpagina in een onzichtbaar iframe op een andere site laadt. Bezoekers denken dat ze op jouw site inloggen, maar klikken in werkelijkheid op knoppen die de aanvaller heeft geplaatst. De header X-Frame-Options voorkomt dit door browsers te verbieden je pagina's in een iframe te laden. Voor een MKB-bedrijf met een klantportaal, online factuuromgeving of B2B-platform is dit essentieel. Je stelt X-Frame-Options in op DENY (helemaal geen iframes) of SAMEORIGIN (alleen iframes van je eigen domein). Een alternatief is de frame-ancestors-directive binnen Content-Security-Policy, die meer flexibiliteit biedt. Bij een goed beveiligde webontwikkelomgeving worden deze headers standaard meegeleverd, zodat je inlogpagina's niet misbruikt kunnen worden.

Afdwingen van HTTPS-verbindingen met Strict-Transport-Security

Strict-Transport-Security (HSTS) is een header die browsers dwingt om alleen via HTTPS met je site te communiceren, zelfs als een gebruiker per ongeluk een HTTP-link volgt. Dit voorkomt man-in-the-middle-aanvallen waarbij een aanvaller zich tussen de gebruiker en je server plaatst om data te onderscheppen. Voor een webshop of dienstverlener die persoonsgegevens verwerkt, is HSTS een harde eis vanuit de Autoriteit Persoonsgegevens. Je stelt HSTS in met een max-age-waarde (bijvoorbeeld een jaar) en optioneel de includeSubDomains-directive als je ook subdomains wilt beschermen. Let op: HSTS is onomkeerbaar voor de duur van de max-age-periode. Als je HTTPS later uitschakelt, kunnen bezoekers je site niet meer bereiken. Daarom test je eerst met een korte max-age-waarde voordat je de header definitief activeert.

Wanneer security headers de juiste keuze zijn en wanneer niet

Security headers zijn bijna altijd zinvol, maar de configuratie verschilt per situatie. Voor een statische website zonder formulieren of inlogfunctie volstaan basis-headers zoals X-Content-Type-Options en Referrer-Policy. Voor een webshop of klantportaal heb je een strikte Content-Security-Policy en HSTS nodig. Security headers zijn geen vervanging voor andere beveiligingsmaatregelen zoals regelmatige updates, sterke wachtwoorden en two-factor authentication. Ze werken het beste als onderdeel van een bredere beveiligingsstrategie. Wanneer je site afhankelijk is van veel externe scripts (advertentienetwerken, chatbots, A/B-testing-tools), kan een te strikte CSP ervoor zorgen dat functionaliteit uitvalt. In dat geval stel je CSP geleidelijk in en monitor je de console-errors in je browser om te zien welke bronnen geblokkeerd worden.