Security headers check voor betere browserbeveiliging
Security headers zijn instellingen die je server of CMS met elke pagina meestuurt en die de browser vertellen hoe hij veilig met je site moet omgaan. Ze bepalen onder andere of een verbinding altijd versleuteld is, of je site in een frame mag worden geladen en welke scripts mogen draaien. Goed ingestelde headers maken aanvallen zoals clickjacking, code-injectie en afluisteren een stuk moeilijker, zonder dat je bezoeker er iets van merkt.
Controlepunten
Waarom dit belangrijk is
Security headers zijn een van de goedkoopste manieren om de aanvalsoppervlakte van een website te verkleinen, want ze kosten geen extra code in je pagina's maar voegen wel een verdedigingslaag toe in de browser. Zonder HSTS kan een bezoeker via een onversleutelde eerste aanvraag worden omgeleid naar een nepsite of worden afgeluisterd op openbaar wifi. Zonder een goede Content-Security-Policy of frame-ancestors kan een aanvaller jouw pagina in een onzichtbaar frame stoppen en bezoekers ongemerkt op verborgen knoppen laten klikken (clickjacking), of geinjecteerde scripts laten uitvoeren. Voor vertrouwen telt dit dubbel: securityscanners, sommige browsers en zakelijke inkopers kijken expliciet naar deze headers, en een lage score komt terug in security-audits en leveranciersvragenlijsten. Het raakt zelden direct je positie in Google, maar wel je betrouwbaarheid richting klanten en partners, en het voorkomt incidenten die wel reputatie- en conversieschade veroorzaken. Het mooie is dat de meeste headers eenmalig instelbaar zijn op serverniveau en daarna automatisch voor je hele site gelden.
Veelvoorkomende bevindingen
Security headers zijn regels in het HTTP-antwoord dat je server bij elke pagina meestuurt, nog voordat de eigenlijke inhoud wordt geladen. De browser leest ze en past zijn gedrag aan: hij weet dan bijvoorbeeld dat hij voortaan alleen nog via HTTPS met je site mag praten (HSTS), welke scripts en stijlen hij mag uitvoeren (Content-Security-Policy), en of je pagina in een frame op een ander domein mag verschijnen (X-Frame-Options / frame-ancestors). Het gaat dus niet om iets dat de bezoeker ziet, maar om afspraken tussen jouw server en de browser over wat wel en niet mag.
HSTS (Strict-Transport-Security) zorgt ervoor dat de browser, nadat hij je site een keer veilig heeft bezocht, gedurende de ingestelde max-age automatisch HTTPS afdwingt, zelfs als iemand http intikt. Dit dicht het gat waarin een aanvaller op een onveilig netwerk de eerste, nog onversleutelde aanvraag onderschept. Met includeSubDomains geldt dat ook voor al je subdomeinen, en met preload kun je je domein laten opnemen in een lijst die browsers vooraf kennen. Belangrijk: zet HSTS pas hard aan als je zeker weet dat alles (ook subdomeinen) blijvend op HTTPS draait, want een te agressieve instelling kan je site tijdelijk onbereikbaar maken als HTTPS ergens hapert.
Content-Security-Policy (CSP) is de krachtigste maar ook de lastigste header. Hij vertelt de browser uit welke bronnen scripts, stijlen, afbeeldingen en andere content mogen komen, en is daarmee de belangrijkste verdediging tegen cross-site scripting (XSS). Waar het misgaat: veel sites zetten ofwel helemaal geen CSP, ofwel een policy met 'unsafe-inline' en wildcards die zo ruim is dat hij in de praktijk weinig tegenhoudt. Een goede CSP is specifiek (alleen de domeinen die je echt gebruikt), vermijdt inline scripts waar mogelijk, en kan eerst in 'report-only'-modus draaien zodat je ziet wat er zou breken voordat je echt blokkeert. Aan CSP frame-ancestors hang je meteen je clickjacking-bescherming op, als modern alternatief voor X-Frame-Options.
De kleinere headers doen elk hun deel. X-Content-Type-Options: nosniff verbiedt de browser om het bestandstype te raden, wat voorkomt dat bijvoorbeeld een geupload bestand als script wordt uitgevoerd. Referrer-Policy bepaalt hoeveel van de huidige URL wordt meegestuurd als een bezoeker doorklikt naar een ander domein; zonder een veilige waarde kunnen paden of tokens in de verwijzer-header lekken. Permissions-Policy (de opvolger van Feature-Policy) schakelt browserfuncties als camera, microfoon en geolocatie standaard uit, zodat ingesloten of geinjecteerde content er niet ongevraagd om kan vragen. Een verouderde header als X-XSS-Protection kan beter weg, omdat moderne browsers die niet meer gebruiken en hij in zeldzame gevallen juist problemen gaf.
CheckBorg controleert of deze headers aanwezig zijn en signaleert waar ze ontbreken, te zwak staan of inconsistent worden meegestuurd, en geeft aan welke het zwaarst wegen. We lossen het niet voor je op: de daadwerkelijke fix gebeurt in je hosting, webserver (zoals Nginx of Apache), een reverse proxy of CDN, of in je CMS- of applicatieconfiguratie. Wat wij wel doen is helder maken wat er nu mist, in welke volgorde je het beste begint, en waar een instelling extra voorzichtigheid vraagt (zoals een te strenge CSP of HSTS-preload) zodat je niets per ongeluk sloopt.
Hoe pak je het aan
Begin bij HSTS en HTTPS-fundament
Zorg eerst dat je hele site (inclusief subdomeinen) blijvend op HTTPS draait, en stel dan Strict-Transport-Security in met een ruime max-age (bijvoorbeeld een jaar). Dit doe je in je webserver, reverse proxy of CDN. Voeg includeSubDomains pas toe als je zeker bent dat alle subdomeinen HTTPS hebben, en overweeg preload als laatste, onomkeerbare stap.
Voeg de eenvoudige headers in een keer toe
X-Content-Type-Options: nosniff, een veilige Referrer-Policy (zoals strict-origin-when-cross-origin) en een Permissions-Policy die camera, microfoon en geolocatie afschermt zijn laag risico en snel te zetten. Voeg ze centraal toe in je serverconfiguratie zodat ze voor elke pagina gelden.
Bescherm tegen clickjacking
Stel frame-ancestors in via je Content-Security-Policy (of, voor oudere clients, X-Frame-Options) zodat je site niet in frames van vreemde domeinen kan worden geladen. Geef alleen de domeinen op die je echt nodig hebt, bijvoorbeeld als je eigen content ergens insluit.
Bouw de Content-Security-Policy stapsgewijs op
Begin met CSP in Content-Security-Policy-Report-Only en verzamel meldingen, zodat je ziet welke scripts en bronnen je site echt gebruikt voordat je iets blokkeert. Werk toe naar een specifieke policy zonder onnodige 'unsafe-inline'. Dit is de meest tijdrovende stap en raakt vaak je CMS, thema's en externe scripts.
Test en houd het consistent
Controleer na het instellen dat de headers op alle HTTPS-pagina's en na redirects daadwerkelijk meekomen, want een verkeerd geplaatste regel geldt soms maar voor een deel van je site. Herhaal de controle na grote CMS- of hostingwijzigingen, omdat updates instellingen kunnen overschrijven.
Schakel een specialist in bij maatwerk
Heb je een complexe applicatie met veel externe scripts, betaalproviders of embeds, dan loont het om je server- of CMS-beheerder of een securityspecialist de CSP te laten fijnslijpen. Een te strenge policy kan functionaliteit breken, een te losse biedt nauwelijks bescherming.
Controleer je eigen website
Vul je domein in en ontdek welke checks aandacht nodig hebben.
Veelgestelde vragen
Maken security headers mijn website veiliger zonder dat ik mijn code hoef te wijzigen?
Grotendeels wel. De meeste headers (HSTS, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, frame-ancestors) stel je eenmalig in op je server, proxy of CDN en gelden dan voor je hele site. Alleen een strenge Content-Security-Policy vraagt soms aanpassingen, omdat inline scripts of externe bronnen geblokkeerd kunnen worden.
Beïnvloeden security headers mijn positie in Google?
Niet direct als rankingfactor. HTTPS zelf is wel een licht signaal, en HSTS helpt dat te borgen. Het echte belang zit in veiligheid en vertrouwen: voorkomen van incidenten, en een betere indruk bij securityscanners en zakelijke inkopers die deze headers controleren.
Wat is het verschil tussen X-Frame-Options en CSP frame-ancestors?
Beide beschermen tegen clickjacking door te bepalen of je pagina in een frame mag worden geladen. X-Frame-Options is de oudere, eenvoudigere variant; frame-ancestors in de Content-Security-Policy is de modernere opvolger met meer controle. In de praktijk zet je vaak beide, zodat ook oudere browsers gedekt zijn.
Is HSTS met preload riskant?
Het vraagt voorzichtigheid. Preload zet je domein op een lijst die browsers vooraf kennen, waardoor http definitief wordt geweigerd. Dat is sterk, maar lastig terug te draaien. Zet het pas aan als je hele domein en alle subdomeinen blijvend en betrouwbaar op HTTPS draaien.
Lost CheckBorg ontbrekende headers automatisch op?
Nee. CheckBorg detecteert welke headers ontbreken of te zwak staan, prioriteert ze en legt uit waarom ze tellen. De daadwerkelijke instelling gebeurt in je hosting, webserver, reverse proxy, CDN of CMS. Voor complexe gevallen, vooral bij de Content-Security-Policy, kan een server- of securityspecialist helpen.
Waarom krijg ik een waarschuwing terwijl mijn site gewoon op HTTPS draait?
HTTPS regelt de versleuteling, maar de headers regelen het gedrag van de browser daaromheen. Je kunt een geldig HTTPS-certificaat hebben en toch geen HSTS, geen CSP en geen clickjacking-bescherming meesturen. CheckBorg kijkt naar die headers afzonderlijk, dus een veilige verbinding betekent niet automatisch dat alle headers goed staan.