Wat zijn security headers en waarom mist bijna elke website er een paar?

Een security header is een regel in het HTTP-antwoord dat je server terugstuurt zodra een browser een pagina opvraagt. Naast de inhoud van de pagina krijgt de browser een set instructies mee, en een deel daarvan gaat specifiek over veiligheid. De browser leest die instructies en past zijn gedrag aan: hij weigert bijvoorbeeld scripts van onbekende bronnen, blokkeert dat je site in een frame van iemand anders wordt geladen, of dwingt af dat verbindingen altijd via HTTPS lopen.

Het verschil met andere beveiliging is dat security headers in de browser werken, niet op de server. Een firewall of WAF houdt aanvallen tegen voordat ze je server raken. Security headers doen iets anders: ze instrueren de browser van de bezoeker om bepaald risicovol gedrag te weigeren. Daardoor beschermen ze vooral tegen aanvallen die zich in de browser van de gebruiker afspelen, zoals cross-site scripting en clickjacking.

Je ziet de headers normaal niet als bezoeker. Ze zijn alleen zichtbaar in de ontwikkelaarstools van je browser (tabblad Netwerk) of via een scan. Dat is precies waarom ze zo vaak ontbreken: een site oogt prima zonder, en het gemis valt pas op als iemand er gericht naar kijkt of als er een incident is.

HSTS (Strict-Transport-Security) dwingt af dat de browser je site altijd via HTTPS benadert, ook als iemand per ongeluk http typt of op een oude link klikt. Dat voorkomt dat verkeer in een onversleuteld moment kan worden onderschept. HSTS werkt pas goed als HTTPS overal stabiel draait, want eenmaal ingesteld onthoudt de browser de regel een lange tijd.

Content-Security-Policy (CSP) is de krachtigste maar ook lastigste header. Hiermee bepaal je welke bronnen scripts, styles, afbeeldingen en frames mogen leveren. Een goede CSP maakt cross-site scripting veel moeilijker, omdat ingeslopen scripts simpelweg niet meer worden uitgevoerd. De keerzijde: een te strenge of slecht geteste CSP breekt makkelijk legitieme functionaliteit zoals analytics, embeds of betaalwidgets.

X-Frame-Options (of de frame-ancestors-regel binnen CSP) voorkomt clickjacking door te blokkeren dat jouw site in een frame van een andere site wordt geladen. Referrer-Policy bepaalt hoeveel informatie over de herkomst-URL wordt meegestuurd als een bezoeker doorklikt, wat datalekkage via verwijzingen beperkt. Permissions-Policy regelt welke browserfuncties (camera, microfoon, locatie, geolocatie) een pagina mag aanspreken. Samen vormen deze vijf de praktische basis die je op vrijwel elke website wilt hebben.

In de praktijk scoort het overgrote deel van de websites onvolledig op security headers. Dat heeft zelden met onwil te maken en bijna altijd met onzichtbaarheid. Een site bouwt en deployt prima zonder deze headers, er komt geen foutmelding, en niemand merkt het verschil in dagelijks gebruik. Pas bij een gerichte controle of een incident komt het tekort naar boven.

Een tweede oorzaak is verdeelde verantwoordelijkheid. Headers kunnen worden ingesteld in de applicatie, op de webserver (zoals Nginx of Apache), bij de hosting of in een CDN dat ervoor zit. Bij een doorsnee mkb-site is vaak niet één partij eindverantwoordelijk, waardoor iedereen aanneemt dat een ander het regelt. Het resultaat: niemand doet het.

De derde reden is voorzichtigheid rond CSP. Omdat een verkeerde CSP zichtbaar dingen kan breken, durven bouwers hem niet aan te zetten en blijft hij achterwege. Dat is begrijpelijk, maar leidt ertoe dat juist de waardevolste header het vaakst ontbreekt. De makkelijkere headers zoals X-Frame-Options en Referrer-Policy worden dan ook overgeslagen, terwijl die met veel minder risico aan te zetten zijn.

Begin nooit met de strengste instelling in productie. Werk in lagen en test na elke wijziging. Start met de headers die weinig kunnen breken: X-Frame-Options, Referrer-Policy en Permissions-Policy. Die kun je in de meeste gevallen direct aanzetten zonder dat bezoekers er iets van merken, en ze leveren meteen winst op tegen clickjacking en onnodige datalekkage.

HSTS zet je pas aan als HTTPS overal werkt, inclusief subdomeinen waar je dat wilt afdwingen. Schakel niet meteen de allerlangste geldigheidsduur of de preload-optie in, want een fout daarin is lastig terug te draaien omdat browsers de regel onthouden. Bouw de geldigheidsduur rustig op zodra je zeker weet dat alle HTTPS-verbindingen kloppen.

CSP verdient de meeste zorg. Zet hem eerst in report-only modus: de browser rapporteert dan welke bronnen tegen de regels in zouden gaan, zonder daadwerkelijk iets te blokkeren. Zo zie je precies welke scripts, styles, fonts en externe diensten je site echt gebruikt. Pas als het rapport schoon is en je begrijpt waar elke bron vandaan komt, schakel je over naar afdwingen. Houd er rekening mee dat CDN, hosting en applicatie elkaars headers kunnen overschrijven; controleer dus wat de bezoeker uiteindelijk binnenkrijgt, niet alleen wat je in één laag hebt ingesteld.

Voor mkb-ondernemers zijn security headers een professionele basismaatregel, vergelijkbaar met een geldig SSL-certificaat. Je hoeft de techniek niet zelf te beheersen, maar het is verstandig om te weten dat ze bestaan en om ernaar te vragen bij wie je website beheert. Een eenvoudige vraag als 'staan onze basis security headers goed?' maakt vaak duidelijk of er over is nagedacht. Het kost je leverancier doorgaans weinig tijd om de veilige basisheaders aan te zetten.

Voor webbureaus en technische teams zijn headers een kans om kwaliteit zichtbaar te maken. Veel klanten zien niet wat er achter de schermen aan onderhoud gebeurt. Door headers standaard in je oplevering mee te nemen en in een rapport te tonen, vertaal je onzichtbaar werk naar een concreet kwaliteitspunt. Het onderscheidt een professioneel gebouwde site van een snel in elkaar gezette.

Voor beide groepen geldt dat security headers geen complete beveiliging zijn. Ze vervangen geen updates, geen sterke wachtwoorden, geen back-ups en geen goede toegangsrechten. Ze zijn een laag in een groter geheel: goedkoop, effectief en daarom een logisch beginpunt, maar niet het eindstation.

Een gratis CheckBorg-scan controleert welke security headers je website meestuurt en welke ontbreken of zwak zijn ingesteld. Je krijgt per header te zien wat er staat, wat het effect is en welke punten prioriteit verdienen. Zo hoef je niet zelf in de ontwikkelaarstools te duiken om te ontdekken waar het misgaat.

CheckBorg is bewust feitelijk en doet niet alsof headers een volledige beveiligingsoplossing zijn. De scan signaleert: hij zegt welke header mist, niet dat je site daarmee per definitie onveilig of veilig is. Die nuchtere lijn past bij hoe een onafhankelijke meter hoort te werken, met klanten, Google en ChatGPT als referentiekader in plaats van een verkoopverhaal.

Voor bureaus is de scan handig om vóór oplevering een nulmeting te doen en na livegang te controleren of de headers ook echt bij de bezoeker aankomen, zodat een CDN- of hostinglaag ze niet alsnog overschrijft. Voor ondernemers is het een snelle manier om te zien of je leverancier de basis op orde heeft. Draai de scan, neem de bevindingen mee naar wie je site beheert en bepaal samen welke headers je als eerste aanzet.