Je hebt een website of webshop live staan, een SSL-certificaat geregeld, en je ziet het groene slotje in de browser. Alles veilig, toch? Niet helemaal. Een aanvaller kan jouw betaalpagina in een onzichtbaar frame laden op een andere site, elke toetsaanslag registreren en gegevens onderscheppen, manieren die onder online beveiligingstechnieken vallen, zonder dat jij of je bezoeker iets merkt. Deze techniek werkt alleen als jouw webserver bepaalde instructies niet meegeeft aan de browser. Die instructies heten security headers, en bij de meeste websites staan ze standaard niet goed ingesteld.
Wat een aanvaller ziet als jouw security headers ontbreken
Hackers kijken niet alleen naar wachtwoorden of verouderde plugins. Ze scannen ook naar ontbrekende beveiligingsinstellingen die de browser van je bezoeker kwetsbaar maken. Twee aanvallen die je daadwerkelijk tegenkomt:
Clickjacking: een aanvaller laadt jouw pagina onzichtbaar in een eigen website. De bezoeker denkt op een knop te klikken, maar klikt in werkelijkheid op jouw pagina die erachter verborgen zit. Zo worden betaalopdrachten, wachtwoordwijzigingen of bestellingen uitgevoerd zonder dat de gebruiker het doorheeft.
Cross-site scripting (XSS): een aanvaller slaagt erin een stukje kwaadaardig JavaScript in jouw pagina te laden, bijvoorbeeld via een commentaarveld of een externe advertentie. Dat script leest dan sessiecookies uit of stuurt bezoekers door naar een neppagina. Zonder de juiste header heeft de browser van je bezoeker geen manier om dat script te weigeren.
Wat security headers precies doen
Security headers zijn instructies die jouw webserver meestuurt aan de browser van elke bezoeker. Ze zijn onzichtbaar voor de gewone gebruiker, maar de browser leest ze en handelt er naar. Vergelijk het met brandwerende deuren in een kantoorgebouw: bezoekers zien ze nauwelijks, maar ze beperken wel de schade als er iets misgaat. Je hoeft geen programmeur te zijn om ze in te stellen, en je hoeft ook de code van je site niet aan te passen. Ze werken op het niveau van de server, een laag onder je website.
De zes headers die er echt toe doen
1. Content-Security-Policy (CSP): de portier die scripts controleert
Met CSP geef je de browser een lijst van bronnen waaruit scripts, afbeeldingen en lettertypes mogen worden geladen. Alles wat niet op die lijst staat, wordt geblokkeerd. Dat klinkt technisch, maar het effect is simpel: als een aanvaller erin slaagt een nep-script in jouw pagina te injecteren, weigert de browser het gewoon uit te voeren. Voor webshops die externe betaalwidgets of chattools gebruiken, is CSP de meest krachtige, maar ook de meest complexe header om goed in te stellen, zeker omdat je moet controleren met welke diensten je werkelijk zaken doet.
2. Strict-Transport-Security (HSTS): altijd HTTPS, nooit HTTP
Je hebt een SSL-certificaat, dus je site draait op HTTPS. Maar wat als iemand toch via HTTP binnenkomt, via een oude link of een typfout? HSTS vertelt de browser: stuur deze gebruiker altijd automatisch door naar HTTPS, en onthoud dat voor de komende maanden. Zo voorkom je dat bezoekers ook maar één seconde via een onbeveiligde verbinding communiceren met jouw server.
3. X-Frame-Options: geen onzichtbare frames toegestaan
Dit is de directe verdediging tegen het clickjacking-scenario uit de opening. Met X-Frame-Options zeg je tegen browsers: laad mijn pagina nooit in een frame of iframe op een andere website. Voor betaalpagina’s en inlogschermen is dit één van de eerste headers die je moet instellen.
4. X-Content-Type-Options: bestanden zijn wat ze zijn
Browsers proberen soms slim te zijn: ze kijken naar de inhoud van een bestand en besluiten het anders te behandelen dan bedoeld. Een tekstbestand kan zo per ongeluk als uitvoerbare code worden gezien. Met deze header zet je dat gedrag uit. Het kost je niets en het instellen duurt letterlijk tien seconden.
5. Referrer-Policy: bepaal wat je deelt als bezoekers doorklikken
Wanneer een bezoeker via een link op jouw site naar een externe pagina gaat, stuurt de browser standaard mee welke pagina de bezoeker verlaat. Dat kan gevoelige informatie bevatten: denk aan zoektermen in een URL, persoonlijke parameters of interne paginanamen. Met Referrer-Policy stel je in hoeveel je deelt, van alles tot niets.
6. Permissions-Policy: trek toestemmingen in die je toch niet gebruikt
Browsers kunnen toegang verlenen tot de camera, microfoon, locatie en andere apparaatfuncties. Als jouw blog of webshop die functies nooit gebruikt, waarom zou je ze dan beschikbaar laten? Met Permissions-Policy schakel je ze expliciet uit. Zo kan een kwaadaardig script dat toch je pagina bereikt, die functies niet misbruiken.
Stap 1: controleer nu jouw huidige score
Ga naar securityheaders.com en vul de URL van jouw website in. Je krijgt binnen enkele seconden een rapport met een rapportcijfer van A tot F. Een F betekent dat de meeste headers volledig ontbreken. Dat is oncomfortabel om te zien, maar het is beter om het nu te weten dan nadat er iets is misgegaan. De site toont per header of die aanwezig is, en geeft een korte uitleg bij elke ontbrekende instelling.
Stap 2: stel vast welke headers prioriteit hebben
Niet elke site heeft exact hetzelfde risicoprofiel. Hier is een praktische prioriteitsvolgorde per type site:
- Blog of informatiesite: begin met X-Content-Type-Options, X-Frame-Options en HSTS. Dat zijn drie eenvoudige headers die weinig configuratie vereisen en direct effect hebben.
- Leadwebsite met contactformulier: voeg Referrer-Policy en Permissions-Policy toe. Je wil niet dat formulierdata of URL-parameters worden gedeeld met externe diensten.
- Webshop: alle zes headers zijn relevant, met CSP en X-Frame-Options als hoogste prioriteit vanwege het risico op betaalfraude en clickjacking.
Stap 3: headers instellen zonder programmeerkennis
Er zijn drie manieren om dit te regelen, zonder één regel code te schrijven.
Via je hostingpanel: veel hostingproviders bieden in cPanel of Plesk een optie om HTTP-headers toe te voegen via een grafische interface. Zoek naar “HTTP Headers” of “Response Headers” in je beheeromgeving.
Via een CMS-plugin: gebruik je WordPress? Dan zijn er plugins zoals “HTTP Headers” of “Security Headers” die je via een overzichtelijk scherm laten instellen welke headers je wil activeren. Wij raden aan altijd de beoordelingen en het updatemoment van een plugin te checken voor je hem installeert.
Via je webhoster vragen: het klinkt simpel, maar het werkt. Stuur je hostingprovider een mail met de vraag welke security headers ze voor jou kunnen instellen op serverniveau. Veel hosters doen dit gratis, zeker voor de basisset.
Stap 4: hertest en begrijp je score
Na elke wijziging test je opnieuw via securityheaders.com. Een A-score betekent dat alle aanbevolen headers aanwezig zijn en correct zijn geconfigureerd. Een B-score betekent dat de basics er staan, maar dat bijvoorbeeld CSP ontbreekt of beperkt is geconfigureerd. Voor een eenvoudige blog is een B-score prima. Voor een webshop streef je naar een A.
Veelgemaakte misvatting: SSL is niet genoeg
Veel beheerders denken: ik heb een SSL-certificaat, dus mijn site is beveiligd. SSL versleutelt de verbinding tussen jouw server en de browser van de bezoeker. Dat is essentieel, maar het zegt niets over wat er op die pagina zelf kan worden uitgevoerd. Een aanvaller die een kwaadaardig script in jouw pagina injecteert, profiteert net zo goed van jouw beveiligde verbinding als een gewone bezoeker. Security headers pakken die laag aan: wat mag de browser doen met de inhoud die hij ontvangt?
Voor webshops: PCI-DSS en je betaalprovider
Als je een webshop beheert die betalingen verwerkt, kom je vroeg of laat in aanraking met PCI-DSS, de beveiligingsstandaard voor bedrijven die met kaartgegevens werken. Die standaard vraagt expliciet om maatregelen tegen XSS en andere injectieaanvallen. Security headers zijn daarin een erkende technische maatregel. Sommige betaalproviders, zoals Mollie of Stripe, stellen in hun documentatie ook aanbevelingen rond CSP. Controleer of jouw betaalprovider specifieke richtlijnen heeft voor de pagina’s waarop hun widget of iframe wordt geladen.
Wanneer schakel je een specialist in?
Doe-het-zelf werkt prima voor de basisset van headers. Maar er zijn situaties waarin het slimmer is om iemand in te schakelen. CSP is de lastigste: een te strenge policy breekt functionaliteit zoals betaalwidgets, chattools of analyses. Als je merkt dat na het instellen van CSP bepaalde onderdelen van je site niet meer werken, is dat het signaal dat de configuratie maatwerk vraagt. Hetzelfde geldt als jouw site meerdere domeinen gebruikt, externe scripts laadt van tientallen bronnen, of als je PCI-DSS-compliance aantoonbaar wil maken. In die gevallen is een uur met een webontwikkelaar of beveiligingsspecialist goedkoper dan de gevolgen van een incident.
Security headers zijn geen geavanceerde maatregel voor grote bedrijven met een IT-afdeling. Je kunt ze vandaag nog controleren via securityheaders.com, en voor de meeste websites is een basisset van drie tot vier headers al een merkbare verbetering. Voor webshops is een complete configuratie geen optie maar een vereiste, zeker als je betaalgegevens of persoonsdata verwerkt. Wij van Informeren.be raden aan om te beginnen met de gratis test, je score te bekijken en daarna te kiezen welke aanpak bij jou past: via je hostingpanel, een plugin of contact met je hoster. Dat is een kwestie van minuten, niet van uren.
