Managed hosting 05 april 2026

Security headers configureren: veilig beginnen

Deel dit artikel

Je website heeft een SSL-certificaat, je software is up-to-date en je wachtwoorden zijn sterk. Maar heb je ook je security headers geconfigureerd? Bij websites die wij scannen, ontbreken regelmatig security headers. Het goede nieuws: ze beschermen tegen hele categorieën aanvallen — van clickjacking tot cross-site scripting. Hoeveel tijd het instellen en testen kost, hangt af van je omgeving; HSTS bouw je daarna in een aantal weken op.

Wat zijn security headers?

Security headers zijn instructies die je webserver meestuurt bij elk HTTP-antwoord. Ze vertellen de browser van je bezoeker hoe die zich moet gedragen: welke content mag worden geladen, of de pagina in een iframe mag worden getoond, of cookies alleen via HTTPS mogen worden verstuurd. Zonder deze headers bepaalt de browser zelf wat er mag — en dat is vaak te ruim.

Je kunt security headers controleren door in je terminal het volgende commando uit te voeren:

curl -sI https://www.jouwdomein.nl | grep -iE "strict-transport|content-security|x-frame|x-content-type|referrer-policy|permissions-policy"

Krijg je weinig of geen resultaten terug? Dan zijn de gezochte headers niet zichtbaar in dit antwoord. Controleer redirects, het antwoord zelf en je configuratie.

Zeven security headers, waarvan één verouderd

1. Strict-Transport-Security (HSTS)

HSTS dwingt browsers om alleen via HTTPS te communiceren met je website. Zonder HSTS kan een aanvaller een bezoeker omleiden naar een HTTP-versie van je site en verkeer onderscheppen (man-in-the-middle aanval).

Strict-Transport-Security: max-age=300

max-age=300 — browser onthoudt dit 5 minuten
includeSubDomains — geldt ook voor alle subdomeinen; voeg dit pas toe als elk subdomein via HTTPS werkt
preload — alleen voor aanmelding bij de HSTS preload list van browsers (zie hieronder)

Begin met een korte max-age en verhoog die stap voor stap, bijvoorbeeld naar een week (max-age=604800), een maand (max-age=2592000) en daarna minimaal een jaar (max-age=31536000). Controleer bij elke stap of alles nog werkt en wacht de volledige max-age af voordat je verder gaat.

Preload is een aparte, bewuste stap: je meldt je domein dan zelf aan via hstspreload.org voor de lijst die in browsers is ingebouwd. Daarvoor moet je domein aan alle eisen voldoen: een geldig certificaat, een doorverwijzing van HTTP naar HTTPS, alle subdomeinen via HTTPS en op het hoofddomein een HSTS-header met een max-age van minimaal een jaar, includeSubDomains en preload. Na acceptatie kan het maanden duren voordat browsers de opname via een update meenemen, en verwijderen van de lijst duurt ook maanden. Volgens hstspreload.org voegt preload weinig toe aan HSTS zelf en wordt het niet aangeraden.

2. Content-Security-Policy (CSP)

Een krachtige maar ook complexe header. CSP bepaalt welke bronnen (scripts, stylesheets, afbeeldingen, fonts) je pagina mag laden. Dit is een belangrijke verdediging tegen cross-site scripting (XSS) aanvallen.

Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' https://fonts.gstatic.com

Begin met een basisbeleid en breid het uit op basis van wat je website nodig heeft. Tip: gebruik Content-Security-Policy-Report-Only om eerst te testen zonder content te blokkeren.

3. X-Content-Type-Options

Voorkomt dat browsers het MIME-type van een bestand raden (MIME-sniffing). Zonder deze header kan een aanvaller een kwaadaardig script uploaden als afbeelding, waarna de browser het toch als script uitvoert.

X-Content-Type-Options: nosniff

Eén regel, geen configuratie nodig. Geen reden om dit niet in te stellen.

4. X-Frame-Options

Bepaalt of je pagina in een iframe mag worden getoond. Zonder deze header kan een aanvaller je site in een onzichtbare iframe laden en bezoekers misleiden om op verkeerde knoppen te klikken (clickjacking).

X-Frame-Options: SAMEORIGIN

DENY — pagina mag nooit in een iframe
SAMEORIGIN — alleen iframes van je eigen domein (aanbevolen)

5. Referrer-Policy

Bepaalt hoeveel informatie je browser deelt over de vorige pagina wanneer een bezoeker op een link klikt. Zonder deze header gebruiken moderne browsers strict-origin-when-cross-origin als standaard; met de header leg je het gedrag zelf vast.

Referrer-Policy: strict-origin-when-cross-origin

Binnen dezelfde origin (zelfde schema, host en poort) stuurt de browser dan het volledige adres mee: origin, pad en querystring. Naar een andere origin met hetzelfde beveiligingsniveau (HTTPS naar HTTPS) gaat alleen de origin mee, en van HTTPS naar HTTP stuurt de browser geen referrer.

6. Permissions-Policy

Bepaalt welke browser-API’s je website mag gebruiken: camera, microfoon, geolocatie, betaalmethoden. Schakel alles uit wat je niet gebruikt — zo voorkom je dat kwaadaardige scripts deze functies misbruiken.

Permissions-Policy: geolocation=(), microphone=(), camera=(), payment=(), usb=()

7. X-XSS-Protection (verouderd)

Deze header is verouderd en geen standaard. Hij stuurde het ingebouwde XSS-filter van oudere browsers aan. Volgens MDN is die bescherming in moderne browsers grotendeels overbodig als je site een sterke Content-Security-Policy gebruikt, en gebruik je de header beter niet in nieuwe projecten. Stuurt je server hem al mee, dan zet deze waarde het oude filter uit:

X-XSS-Protection: 0

Volgens MDN kan het oude filter in sommige gevallen juist XSS-kwetsbaarheden veroorzaken in websites die verder veilig zijn. Bescherming tegen XSS regel je daarom met CSP.

Hoe stel je security headers in?

De configuratie verschilt per webserver. Hier zijn de meest voorkomende:

Liever niet handmatig samenstellen? Met de gratis security headers generator klik je in een paar stappen een set headers bij elkaar. Test die daarna op je eigen site.

Nginx

Voeg de headers toe aan je server- of location-blok:

# HSTS: begin met een korte max-age en verhoog die stap voor stap (zie hierboven)
add_header Strict-Transport-Security "max-age=300" always;
add_header X-Content-Type-Options "nosniff" always;
add_header X-Frame-Options "SAMEORIGIN" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "geolocation=(), microphone=(), camera=(), payment=()" always;
add_header X-XSS-Protection "0" always;

Apache (.htaccess)

# HSTS: begin met een korte max-age en verhoog die stap voor stap (zie hierboven)
Header always set Strict-Transport-Security "max-age=300"
Header always set X-Content-Type-Options "nosniff"
Header always set X-Frame-Options "SAMEORIGIN"
Header always set Referrer-Policy "strict-origin-when-cross-origin"
Header always set Permissions-Policy "geolocation=(), microphone=(), camera=(), payment=()"
Header always set X-XSS-Protection "0"

Controleren of het werkt

Na het instellen kun je je headers controleren:

$ curl -sI https://www.jouwdomein.nl | grep -iE "strict|content-security|x-frame|x-content|referrer|permissions"

strict-transport-security: max-age=300
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN
referrer-policy: strict-origin-when-cross-origin
permissions-policy: geolocation=(), microphone=(), camera=(), payment=()

Dit is een voorbeeld van de uitvoer bij de configuratie hierboven. Ontbreekt er een header die je hebt ingesteld? Controleer dan je configuratie.

Veelgemaakte fouten

Te strenge CSP zonder testen — een verkeerd geconfigureerde CSP breekt je website. Test altijd eerst met Report-Only modus. Twijfel je of je policy klopt? Scan je CSP op zwakke plekken of laat de CSP-generator ’m opbouwen.
Headers alleen op de homepage — security headers moeten op alle pagina’s staan, inclusief API-endpoints en admin-pagina’s.
Dubbele headers — als je webserver én je applicatie headers instellen, krijg je dubbele waarden die conflicteren. Kies één plek.
HSTS te snel op preload zetten — zodra je in de preload list staat, kun je niet snel meer terug naar HTTP: verwijderen van de lijst duurt maanden. Zorg eerst dat alles werkt.

Meer over website security

SPF instellen voor je domein — bescherm je e-mail tegen spoofing met het juiste DNS-record.
Website security check — waarom elke organisatie regelmatig moet scannen op kwetsbaarheden.

Waarom dit ertoe doet

Security headers zijn een laagdrempelige beveiligingsmaatregel: je hebt er geen licentie voor nodig en ze beschermen tegen aanvallen die dagelijks plaatsvinden. Hoeveel tijd het instellen en testen kost, hangt af van je omgeving. Toch ontbreken ze nog op veel websites — vaak simpelweg omdat niemand eraan denkt.

Bij Cobytes Managed Hosting nemen we beveiliging mee in ontwerp en beheer. Aanvullende maatregelen, zoals een Content-Security-Policy die past bij de specifieke services die je website gebruikt (van analytics tot chat widgets), stemmen we af op je omgeving en de afgesproken scope.

Wil je weten of jouw website de juiste security headers heeft? Neem contact met ons op voor een security check — we vertellen je wat er mist en helpen je bij het instellen.