Naar hoofdinhoud

HTTP-beveiligingsheaders instellen: HSTS, CSP en meer

Gepubliceerd op 9 juli 2026 10 min leestijd

Leer wat HTTP-beveiligingsheaders zoals HSTS en CSP doen en stel ze veilig in via .htaccess op Plesk of met een WordPress-plugin. Met stappenplan.

Vlakke illustratie van een persoon naast een groot browservenster met een schild en een slotje, waar kleine kaartjes als beveiligingslagen naartoe zweven en een oranje pijl op afketst, in blauwtinten met een oranje accent.

Heeft een security-scan zoals securityheaders.com of de MDN HTTP Observatory gemeld dat je website beveiligingsheaders mist? HTTP-beveiligingsheaders zoals HSTS en CSP zijn korte instructies die je server bij elke pagina meestuurt en die de browser vertellen hoe hij je site veilig moet behandelen. In dit artikel lees je wat de belangrijkste beveiligingsheaders doen, welke aanvallen ze tegenhouden en hoe je ze instelt via .htaccess op je Plesk-hosting of met een WordPress-plugin.

Wat zijn HTTP-beveiligingsheaders?

Elke keer dat een bezoeker een pagina opvraagt, stuurt je webserver naast de inhoud ook een reeks HTTP-responseheaders mee. Dat zijn korte regels die op de achtergrond meelopen en van alles regelen, van caching tot het type inhoud. Beveiligingsheaders zijn een speciale groep daarvan: ze leggen de browser strengere regels op over wat er met je pagina mag gebeuren.

Beveiligingsheaders vervangen geen veilige code, sterke wachtwoorden of updates. Ze vormen een extra verdedigingslaag, ook wel defense in depth genoemd. Sluipt er toch een fout in je site of in een plugin, dan beperken de headers vaak de schade die een aanvaller kan aanrichten.

Welke aanvallen houden beveiligingsheaders tegen?

Elke header richt zich op een specifiek risico. Dit zijn de belangrijkste:

  • Clickjacking: een aanvaller laadt jouw pagina in een onzichtbaar kader (iframe) op een andere site en verleidt bezoekers tot klikken die ze niet bedoelen. Tegengehouden door X-Frame-Options en CSP.
  • Cross-site scripting (XSS): kwaadaardige scripts die in je pagina worden geïnjecteerd en in de browser van je bezoeker draaien. Beperkt door Content-Security-Policy.
  • Downgrade-aanvallen en SSL-stripping: een aanvaller duwt de bezoeker terug naar een onbeveiligde http-verbinding om mee te lezen. Tegengehouden door HSTS.
  • MIME-sniffing: de browser raadt zelf het bestandstype en voert bijvoorbeeld een geüpload bestand uit als script. Tegengehouden door X-Content-Type-Options.
  • Lekken van gegevens via de verwijzende URL: geregeld met Referrer-Policy.
  • Ongewenst gebruik van camera, microfoon of locatie: geregeld met Permissions-Policy.

De belangrijkste beveiligingsheaders op een rij

De onderstaande tabel geeft een overzicht. Daaronder lees je per header wat hij precies doet en welke waarde een goed startpunt is.

Overzicht van de belangrijkste HTTP-beveiligingsheaders en een veilige startwaarde.
HeaderBeschermt tegenAanbevolen startwaarde
Strict-Transport-SecurityDowngrade-aanvallen, SSL-strippingmax-age=63072000; includeSubDomains
Content-Security-PolicyXSS, code-injectie, clickjackingBegin in report-only (zie hieronder)
X-Frame-OptionsClickjackingSAMEORIGIN
X-Content-Type-OptionsMIME-sniffingnosniff
Referrer-PolicyLekken van URL-gegevensstrict-origin-when-cross-origin
Permissions-PolicyMisbruik van browserfunctiesgeolocation=(), camera=(), microphone=()

Strict-Transport-Security (HSTS)

HSTS dwingt af dat browsers je site uitsluitend via https benaderen, ook als iemand per ongeluk http intypt. De waarde max-age bepaalt hoelang de browser dit onthoudt, in seconden. Met includeSubDomains geldt de regel ook voor al je subdomeinen, en met de optionele preload-vlag laat je je domein opnemen in een lijst die al in browsers is ingebouwd.

Een veelgebruikte, veilige waarde is max-age=63072000 (twee jaar) met includeSubDomains. Belangrijk: een browser accepteert HSTS alleen als de header via https wordt verstuurd. Bij LJPc staat HSTS standaard al aan, zie de paragraaf hieronder.

Content-Security-Policy (CSP)

CSP is de krachtigste, maar ook de lastigste header. Je bepaalt er precies mee welke bronnen (scripts, afbeeldingen, stylesheets) mogen laden en vanaf welke domeinen. Daarmee is CSP je sterkste wapen tegen XSS. De directive frame-ancestors regelt bovendien clickjacking en is de moderne opvolger van X-Frame-Options.

Omdat een te strenge CSP je site kan breken, stel je hem het beste eerst in report-only-modus in. Verderop leggen we die aanpak stap voor stap uit.

X-Frame-Options

Deze header bepaalt of je pagina in een iframe op een andere site geladen mag worden en beschermt zo tegen clickjacking. De waarde SAMEORIGIN staat framing alleen toe op je eigen domein, en DENY verbiedt het volledig. De oude waarde ALLOW-FROM is verouderd en wordt door moderne browsers genegeerd.

CSP frame-ancestors doet hetzelfde, maar uitgebreider. Je mag beide instellen: oudere browsers begrijpen alleen X-Frame-Options, nieuwe volgen frame-ancestors.

X-Content-Type-Options

De enige geldige waarde is nosniff. Hiermee verbied je de browser om zelf te raden wat voor bestand hij binnenkrijgt. Zonder deze header kan een browser bijvoorbeeld een geüpload tekstbestand als HTML of script uitvoeren, wat XSS mogelijk maakt.

Referrer-Policy

Deze header bepaalt hoeveel van de vorige URL wordt meegestuurd als een bezoeker vanaf jouw site doorklikt. De waarde strict-origin-when-cross-origin stuurt binnen je eigen site het volledige adres mee, maar naar andere sites alleen je domein zonder pad. Moderne browsers gebruiken dit al als standaard, maar het expliciet instellen maakt je bedoeling duidelijk.

Permissions-Policy

Met Permissions-Policy (de opvolger van Feature-Policy) bepaal je welke browserfuncties je pagina mag gebruiken, zoals camera, microfoon en locatie. Een lege lijst tussen haakjes, bijvoorbeeld camera=(), schakelt een functie volledig uit. Zet alle functies uit die je site niet nodig heeft.

Een verouderde header die je nog wel eens in scans tegenkomt, is X-XSS-Protection. Die wordt afgeraden: zet hem niet meer in, of geef hem de waarde 0. CSP heeft zijn taak overgenomen.

Wat LJPc al voor je regelt: HSTS en OCSP stapling

Zodra er een SSL-certificaat op je website wordt geactiveerd, zet LJPc HSTS automatisch aan met een max-age van twee jaar en includeSubDomains. Ook OCSP stapling staat standaard aan. Dat laatste is een versnelling van de https-handshake, geen header die je zelf beheert. Je hoeft de HSTS-header dus niet zelf toe te voegen, en je kunt dat beter ook niet via .htaccess doen, want dan riskeer je een dubbele header.

HSTS werkt alleen als je site echt via https bereikbaar is. Zorg daarom eerst voor een geldig SSL-certificaat. Bij elk hostingpakket krijg je een gratis Let's Encrypt-certificaat dat automatisch wordt uitgegeven en verlengd. Richt je eigen werk daarom op de andere headers: CSP, X-Frame-Options, X-Content-Type-Options, Referrer-Policy en Permissions-Policy.

Beveiligingsheaders instellen via .htaccess op Plesk

Op Plesk-hosting met Apache lees je headers het eenvoudigst in via het bestand .htaccess in de map httpdocs. Apache stuurt de headers dan mee met elke pagina. Ga zo te werk:

  1. Maak eerst een back-up van je huidige .htaccess, zodat je altijd kunt terugzetten.
  2. Open .htaccess in de bestandsbeheerder van Plesk of via FTP/SFTP. Bestaat het bestand nog niet, maak het dan aan in de webhoofdmap httpdocs.
  3. Plak het onderstaande blok bovenaan het bestand en sla het op.
  4. Ververs je site en controleer of alles nog werkt. Test daarna je headers (zie verderop).
<IfModule mod_headers.c>
    Header always set X-Frame-Options "SAMEORIGIN"
    Header always set X-Content-Type-Options "nosniff"
    Header always set Referrer-Policy "strict-origin-when-cross-origin"
    Header always set Permissions-Policy "geolocation=(), camera=(), microphone=()"
</IfModule>

Het sleutelwoord always zorgt dat de header ook wordt meegestuurd bij foutpagina's zoals een 404. De regel met IfModule voorkomt een foutmelding als de module mod_headers een keer niet actief is. HSTS staat bewust niet in dit blok, omdat LJPc die al voor je verstuurt. Heb je liever geen .htaccess, en geeft je pakket toegang tot de Apache- en nginx-instellingen in Plesk, dan kun je dezelfde regels ook kwijt in het veld voor extra Apache-directives.

Beveiligingsheaders instellen in WordPress

Wil je geen .htaccess bewerken, dan kun je in WordPress een plugin gebruiken. Een veelgebruikte, gratis optie is Headers Security Advanced & HSTS WP, die de headers voor je toevoegt via een instellingenscherm.

  1. Ga in je WordPress-beheer naar Plugins en dan Nieuwe plugin, en zoek op Headers Security Advanced.
  2. Installeer en activeer de plugin.
  3. Open de instellingen van de plugin en zet de gewenste headers aan: X-Frame-Options, X-Content-Type-Options, Referrer-Policy en Permissions-Policy.
  4. Laat HSTS uitgeschakeld, want die verstuurt LJPc al. Zo voorkom je een dubbele header.
  5. Wees voorzichtig met de CSP-optie: schakel die pas in nadat je hem hebt getest, anders kunnen scripts of stijlen wegvallen.

Let op: een plugin en een .htaccess-regel kunnen dezelfde header allebei sturen. Kies daarom per header een methode, zodat je geen dubbele waarden krijgt.

Content-Security-Policy instellen zonder je site te breken

CSP is de header die het vaakst iets stukmaakt, doordat legitieme scripts of stijlen ineens geblokkeerd worden. Vooral bij WordPress, dat veel inline-scripts en -stijlen gebruikt, is voorzichtigheid geboden. Pak het gefaseerd aan:

  1. Begin met de report-only-variant. Die rapporteert overtredingen wel, maar blokkeert nog niets. In .htaccess ziet dat er zo uit:
Header always set Content-Security-Policy-Report-Only "default-src 'self'; img-src 'self' data:; style-src 'self' 'unsafe-inline'; script-src 'self'"
  1. Bezoek je site en houd de console van je browser (F12, tabblad Console) in de gaten. Elke geblokkeerde bron verschijnt daar als melding.
  2. Voeg de bronnen die je echt nodig hebt toe aan de juiste directive, bijvoorbeeld het domein van je lettertypen of je statistiekentool.
  3. Werkt alles zonder meldingen, verander dan Content-Security-Policy-Report-Only in Content-Security-Policy. Nu wordt de policy afgedwongen.
  4. Voeg eventueel frame-ancestors 'self' toe als moderne vervanger van X-Frame-Options.

Een strikte CSP zonder 'unsafe-inline' is het veiligst, maar in de praktijk hebben veel WordPress-thema's die uitzondering voor stijlen nodig. Bouw je policy dus rustig op en test na elke wijziging opnieuw.

Controleren of je headers werken

Na het instellen wil je zeker weten dat de headers echt verstuurd worden. Dat kan op drie manieren:

  • Online scanners: securityheaders.com en de MDN HTTP Observatory geven je site een cijfer en tonen welke headers ontbreken.
  • Ontwikkelaarstools in de browser: open F12, ga naar het tabblad Netwerk, herlaad de pagina en klik op het eerste verzoek. Onder Response Headers zie je de verstuurde headers.
  • Commandoregel: met het commando curl -I https://jouwdomein.nl vraag je alleen de headers op.

Veelvoorkomende problemen

Veelvoorkomende problemen bij het instellen van beveiligingsheaders en hoe je ze oplost.
ProbleemOorzaakOplossing
Header verschijnt nietmod_headers is niet actief of je site draait via een aparte serverconfiguratieControleer of mod_headers aanstaat, of neem contact op met support
Dubbele Strict-Transport-SecurityJe hebt HSTS zelf toegevoegd terwijl LJPc die al verstuurtVerwijder je eigen HSTS-regel
Site of onderdelen werken niet meerEen te strenge Content-Security-Policy blokkeert scripts of stijlenZet CSP terug op report-only en voeg de ontbrekende bronnen toe
Header ontbreekt op foutpagina'sJe gebruikte set in plaats van alwaysGebruik Header always set
Wijziging is niet zichtbaarCaching in je browser of hostingLeeg de cache en test opnieuw, of test met curl

Kom je er niet uit, of wil je zeker weten dat je headers goed staan? Neem gerust contact op met de support van LJPc, dan kijken we met je mee.

Veelgestelde vragen

Wat zijn HTTP-beveiligingsheaders?

Het zijn korte instructies die je webserver bij elke pagina meestuurt en die de browser vertellen hoe hij je site veilig moet behandelen. Denk aan het afdwingen van https, het blokkeren van framing en het beperken van scripts. Samen vormen ze een extra beveiligingslaag boven op veilige code en updates.

Welke beveiligingsheaders zijn het belangrijkst?

De zes die je op vrijwel elke site wilt hebben, zijn Strict-Transport-Security (HSTS), Content-Security-Policy, X-Frame-Options, X-Content-Type-Options, Referrer-Policy en Permissions-Policy. Samen dekken ze de meest voorkomende risico's af, zoals downgrade-aanvallen, XSS en clickjacking.

Moet ik HSTS zelf instellen bij LJPc?

Nee. LJPc zet HSTS automatisch aan zodra er een SSL-certificaat op je site wordt geactiveerd, met een max-age van twee jaar en includeSubDomains. Voeg de header dus niet zelf nog een keer toe, anders krijg je een dubbele Strict-Transport-Security-header.

Waarom werkt mijn site niet meer na het instellen van Content-Security-Policy?

Meestal is de policy te streng, waardoor legitieme scripts of stijlen worden geblokkeerd. Zet CSP eerst in report-only-modus, kijk in de console van je browser welke bronnen worden geblokkeerd en voeg die toe. Zet de policy pas hard aan als alles zonder meldingen werkt.

Hoe controleer ik mijn beveiligingsheaders?

Gebruik een online scanner zoals securityheaders.com of de MDN HTTP Observatory voor een cijfer en een overzicht. In je browser open je met F12 het tabblad Netwerk om de Response Headers te bekijken, en met curl -I https://jouwdomein.nl vraag je ze op de commandoregel op.

Is X-XSS-Protection nog nodig?

Nee, die header is verouderd en wordt afgeraden. Laat hem weg of geef hem de waarde 0. Content-Security-Policy biedt tegenwoordig een veel betere bescherming tegen XSS.

Toch liever iemand spreken?

We geven je ook graag persoonlijk antwoord op je vragen. Plan een gratis adviesgesprek of bel ons direct. We denken graag met je mee.

Blijf op de hoogte van recente ontwikkelingen! Schrijf je in en ontvang onze nieuwsbrief Bezig met aanmelden... Bedankt voor je inschrijving! Er ging iets mis. Probeer het later opnieuw.