Wat zijn HTTP security headers?

Wanneer je een webpagina opent, communiceert je browser met de server waarop de website staat.

Tijdens die communicatie worden zogenaamde HTTP headers meegestuurd. Die bevatten aanvullende informatie en instructies over de request of response.

Sommige van die headers hebben specifiek met beveiliging te maken.

Met een security header kan een server bijvoorbeeld aangeven dat een website alleen via HTTPS geopend mag worden of bepalen vanaf welke locaties scripts, afbeeldingen en andere bronnen geladen mogen worden.

Je ziet deze headers normaal niet op de website zelf. Ze worden op de achtergrond door de browser verwerkt.

De HTTP-documentatie van MDN bevat een uitgebreid overzicht van beschikbare headers en hun functies.

Waarom zijn security headers belangrijk?

Een moderne website bestaat zelden alleen uit HTML en CSS.

Er worden scripts uitgevoerd, lettertypes geladen, formulieren verwerkt, externe diensten gekoppeld en soms video’s, kaarten of andere content ingebed.

Dat creëert mogelijkheden, maar ook potentiële aanvalsvectoren.

Security headers kunnen browsers beperkingen opleggen en daarmee bepaalde risico’s verkleinen. Ze kunnen bijvoorbeeld helpen beschermen tegen cross-site scripting (XSS), clickjacking, MIME-type sniffing en ongewenst gebruik van browserfunctionaliteit.

Zie ze daarbij niet als een volledige beveiligingsoplossing.

Een WordPress-website met kwetsbare plugins wordt niet plots veilig omdat er vijf security headers zijn ingesteld. Updates, sterke authenticatie, correcte rechten, veilige code, back-ups, hosting en andere beveiligingsmaatregelen blijven belangrijk.

Security headers zijn één beveiligingslaag binnen een groter geheel.

Welke security headers zijn belangrijk?

Er bestaan verschillende HTTP headers die een rol kunnen spelen bij websitebeveiliging. Welke configuratie geschikt is, hangt af van de website.

Een aantal headers kom je bijzonder vaak tegen.

Content-Security-Policy (CSP)

Een Content Security Policy bepaalt welke bronnen een browser voor een pagina mag laden.

Je kunt bijvoorbeeld vastleggen vanaf welke domeinen JavaScript, CSS, afbeeldingen, lettertypes of frames toegestaan zijn.

Dat maakt CSP een krachtige extra verdedigingslaag tegen onder andere cross-site scripting (XSS).

Stel dat een website normaal alleen JavaScript vanaf het eigen domein en een aantal vertrouwde externe diensten nodig heeft. Met een goede CSP kun je voorkomen dat de browser zomaar scripts vanaf willekeurige andere locaties uitvoert.

Maar juist doordat CSP zoveel kan beperken, vraagt deze header extra aandacht.

Een te strenge configuratie kan legitieme onderdelen van je website blokkeren: formulieren, video’s, tracking, externe lettertypes of andere integraties kunnen plots niet meer functioneren.

Daarom moet een Content Security Policy afgestemd en getest worden op de website waarop hij wordt toegepast.

Wie technisch verder wil lezen, vindt een uitgebreide uitleg in de Content Security Policy-documentatie van MDN.

Strict-Transport-Security (HSTS)

HTTP Strict Transport Security, meestal afgekort tot HSTS, vertelt een browser dat een website uitsluitend via een beveiligde HTTPS-verbinding benaderd moet worden.

Wanneer HSTS actief is, zal de browser toekomstige verbindingen met die website via HTTPS laten verlopen binnen de ingestelde periode.

Dat biedt extra bescherming tegen situaties waarin een bezoeker onbedoeld via een onbeveiligde HTTP-verbinding verbinding probeert te maken.

HSTS moet wel zorgvuldig worden ingesteld. Een verkeerde configuratie kan problemen veroorzaken, zeker wanneer subdomeinen worden meegenomen.

X-Content-Type-Options

Met X-Content-Type-Options kun je voorkomen dat browsers zelf proberen te raden welk type bestand ze ontvangen.

De gebruikelijke instelling is:

X-Content-Type-Options: nosniff

Daarmee wordt de browser opgedragen het opgegeven Content-Type te respecteren in plaats van via zogenaamde MIME sniffing een ander bestandstype te veronderstellen.

Het is een relatief eenvoudige header die een specifieke categorie ongewenst browsergedrag beperkt.

X-Frame-Options

Met X-Frame-Options kun je bepalen of je pagina binnen een frame op een andere pagina mag worden weergegeven.

Dat kan helpen beschermen tegen clickjacking.

Bij clickjacking wordt een pagina bijvoorbeeld onzichtbaar of misleidend over andere content geplaatst, waardoor iemand denkt op een onschuldige knop te klikken terwijl hij in werkelijkheid interactie heeft met een andere website.

Voor moderne websites kan framing ook via de frame-ancestors-directive van Content Security Policy geregeld worden. Welke aanpak geschikt is, hangt af van de gewenste browserondersteuning en configuratie.

Referrer-Policy

Wanneer iemand via een link van jouw website naar een andere pagina gaat, kan de browser informatie meesturen over de pagina waar die bezoeker vandaan kwam.

Referrer-Policy bepaalt hoeveel van die informatie wordt gedeeld.

Je kunt bijvoorbeeld instellen dat bij verzoeken naar een andere website alleen de oorsprong wordt meegestuurd in plaats van de volledige URL.

Dat kan relevant zijn voor privacy en voorkomen dat onnodig veel informatie uit URL’s met externe websites wordt gedeeld.

MDN beschrijft de verschillende mogelijkheden in de documentatie over Referrer-Policy.

Permissions-Policy

Met Permissions-Policy kun je bepalen welke browserfunctionaliteit een website of ingebedde content mag gebruiken.

Denk bijvoorbeeld aan toegang tot de camera, microfoon of geolocatie.

Een website die bepaalde functionaliteit helemaal niet nodig heeft, kan via deze header beperkingen opleggen.

Niet alle onderdelen van Permissions Policy hebben in iedere browser dezelfde ondersteuning. Controleer daarom de actuele browsercompatibiliteit voordat je een uitgebreide policy implementeert.

En wat met X-XSS-Protection?

Wie oudere artikels over security headers leest, komt vaak nog X-XSS-Protection tegen.

Deze header werd vroeger gebruikt om ingebouwde XSS-filters van browsers te activeren.

Vandaag is hij grotendeels achterhaald.

Moderne browsers vertrouwen niet meer op deze oude XSS-filtering en de header is deprecated. Een goed ingestelde Content Security Policy is tegenwoordig een veel relevantere beveiligingsmaatregel tegen XSS.

Dit is meteen een goede reden om security headers niet één keer in te stellen en vervolgens jarenlang te vergeten. Webstandaarden en browsers evolueren.

Security headers zijn geen kwestie van zoveel mogelijk vinkjes verzamelen

Het is verleidelijk om een securitytest uit te voeren en vervolgens iedere ontbrekende header toe te voegen totdat de website een perfecte score behaalt.

Zo eenvoudig is het niet.

Een header moet passen bij de website.

Vooral een Content Security Policy kan functionaliteit blokkeren wanneer hij zonder voldoende kennis wordt toegevoegd. Denk aan externe scripts, Google Fonts, YouTube-video’s, formulieren, Google Maps, analytics of andere diensten die een website gebruikt.

Ook bij HSTS kunnen verkeerde instellingen gevolgen hebben wanneer bijvoorbeeld subdomeinen nog niet volledig via HTTPS functioneren.

Een hogere testscore is dus niet automatisch hetzelfde als een beter beveiligde website.

De configuratie moet technisch correct zijn én passen bij de functionaliteit van de site.

Hoe controleer je de security headers van je website?

Je hoeft niet zelf in de serverconfiguratie te duiken om eerst te controleren welke headers momenteel aanwezig zijn.

Daarvoor bestaan online testtools.

Een tool die we hiervoor gebruiken is Probely Security Headers.

Je voert je domeinnaam in en de test controleert welke relevante HTTP security headers aanwezig zijn en hoe de configuratie wordt beoordeeld.

Zo krijg je snel een eerste indicatie van mogelijke verbeterpunten.

Belangrijk: beschouw zo’n score als een diagnostisch hulpmiddel, niet als een certificaat dat je website veilig of onveilig verklaart.

Een website kan uitstekend scoren op security headers en elders kwetsbaarheden bevatten. Omgekeerd kan een ontbrekende header in een bepaalde technische context minder ernstig zijn dan de score doet vermoeden.

Mijn website scoort slecht. Wat nu?

Een lage score betekent vooral dat je moet bekijken welke headers ontbreken en waarom.

Sommige verbeteringen zijn relatief eenvoudig. Andere, zoals een goede Content Security Policy, vragen eerst een inventarisatie van de bronnen en externe diensten die je website gebruikt.

Voeg daarom niet zomaar een configuratie toe die je op een forum, in ChatGPT of op een andere website vindt.

Twee WordPress-websites kunnen visueel vergelijkbaar zijn en toch totaal verschillende scripts, plugins en externe diensten laden.

Test wijzigingen bovendien op verschillende pagina’s en functies. Controleer bijvoorbeeld formulieren, video’s, kaarten, cookiebeheer, analytics, betaalfunctionaliteit en andere externe integraties.

Kan The Other Concept helpen met security headers?

Ja. Zie je na een security header-test ontbrekende headers of weet je niet welke instellingen geschikt zijn voor jouw website, dan kunnen we de huidige configuratie controleren en de relevante security headers correct implementeren.

Daarbij kijken we niet alleen naar de score van een testtool, maar ook naar de website zelf en de functionaliteit die behouden moet blijven.

Vooral bij Content Security Policy is dat belangrijk: een strengere beveiliging heeft weinig waarde wanneer daardoor formulieren, externe scripts of andere noodzakelijke onderdelen niet meer functioneren.

Wil je weten hoe jouw website ervoor staat? Neem contact op met The Other Concept, dan bekijken we welke verbeteringen relevant zijn.

Hebben security headers invloed op SEO?

Security headers zijn in de eerste plaats een beveiligingsmaatregel, geen SEO-truc.

Je moet ze dus niet toevoegen omdat je verwacht dat een extra header rechtstreeks een hogere positie in Google oplevert.

Toch raken techniek, veiligheid en gebruikservaring elkaar.

HTTPS is bijvoorbeeld al jarenlang de standaard voor moderne websites. Een technisch gezonde website verkleint bovendien de kans op beveiligingsproblemen die de beschikbaarheid of betrouwbaarheid van een site kunnen aantasten.

Security headers passen daarom binnen goed technisch websitebeheer, maar behandel ze niet als een afzonderlijke SEO-rankingfactor.

Security headers zijn één onderdeel van een gezonde website

Websitebeveiliging bestaat uit verschillende lagen.

Security headers voegen daar een nuttige laag aan toe door browsers expliciete instructies te geven over wat wel en niet toegestaan is.

Vooral Content Security Policy, HSTS, X-Content-Type-Options, Referrer-Policy en maatregelen tegen ongewenst framen kunnen afhankelijk van de website relevant zijn.

Maar de juiste configuratie is belangrijker dan simpelweg zoveel mogelijk headers toevoegen.

Test daarom eerst wat momenteel ingesteld is, onderzoek welke verbeteringen relevant zijn en controleer na iedere wijziging of de website nog volledig functioneert.

Technische kwaliteit stopt bovendien niet bij beveiliging. Ook snelheid, toegankelijkheid en technische best practices spelen een rol. Met Google Lighthouse kun je verschillende van die aspecten controleren en mogelijke verbeterpunten ontdekken.

Een goede website is uiteindelijk niet alleen mooi of snel. Ook wat bezoekers niet zien, moet technisch goed in elkaar zitten.