HTTP security headers die elke bedrijfswebsite zou moeten sturen

HTTP security headers zijn instructies die uw webserver met elke pagina meestuurt. Ze vertellen de browser hoe hij met uw site moet omgaan: altijd HTTPS gebruiken, andere sites uw pagina's niet in een frame laten plaatsen, bestandstypen niet raden, scripts alleen laden van plekken die u vertrouwt. Ze kosten geen snelheid en worden één keer ingesteld in de configuratie van de server of het CDN.

Het korte antwoord voor de meeste bedrijfswebsites: stuur Strict-Transport-Security, Content-Security-Policy (minstens met frame-ancestors), X-Content-Type-Options, Referrer-Policy en Permissions-Policy, zet cookies met de juiste attributen en verwijder headers die uw softwareversies verraden. De aanbevolen waarden hieronder volgen de OWASP HTTP Headers Cheat Sheet en MDN.

Ontbrekende headers zijn zelden op zichzelf een noodgeval. Ze tonen hoe zorgvuldig een site is ingericht, en ze sluiten hele categorieën aanvallen in de browser uit.

Zo controleert u uw headers

Vraag de server om de headers van uw homepage:

curl -sI https://yourcompany.com/

Controleer elke hostnaam, niet alleen de hoofdnaam: webshop, login, klantenportaal en eventuele oude stagingservers die nog antwoorden. Headers die in de applicatie worden gezet, verdwijnen vaak op foutpagina's, redirects en statische bestanden, dus test een paar verschillende URL's.

De headers die het waard zijn

Strict-Transport-Security (HSTS)

Vertelt de browser dat hij voor uw domein gedurende een bepaalde tijd alleen HTTPS mag gebruiken, zodat een bezoeker niet ongemerkt naar HTTP kan worden teruggezet.

Strict-Transport-Security: max-age=63072000; includeSubDomains

max-age staat in seconden. Voeg includeSubDomains alleen toe als elk subdomein via HTTPS werkt. Om in de preloadlijsten van browsers te komen, eist hstspreload.org een max-age van minstens 31536000 (1 jaar), includeSubDomains en preload. Preloading is moeilijk terug te draaien, dus voeg het als laatste toe.

Content-Security-Policy (CSP)

Somt de bronnen op waaruit de pagina scripts, stijlen, afbeeldingen en frames mag laden. Een goede policy is de sterkste verdediging in de browser tegen cross-site scripting, maar ze moet op uw site afgestemd zijn. Begin in rapportagemodus met Content-Security-Policy-Report-Only, kijk wat er geblokkeerd zou worden en schakel daarna de handhaving in.

Zelfs vóór een volledige policy is één richtlijn eenvoudig en nuttig:

Content-Security-Policy: frame-ancestors 'self'

frame-ancestors bepaalt welke sites uw pagina's mogen insluiten, wat clickjacking blokkeert. Het moet als header worden gestuurd; in een <meta>-tag werkt het niet.

X-Frame-Options

De oudere manier om framing te blokkeren. OWASP raadt frame-ancestors aan waar mogelijk en X-Frame-Options: DENY (of SAMEORIGIN) als terugval voor oudere browsers.

X-Content-Type-Options

X-Content-Type-Options: nosniff

Voorkomt dat de browser het type van een bestand raadt, zodat een geüpload bestand niet als script kan worden uitgevoerd. Zorg dat uw Content-Type-headers op de hele site kloppen.

Referrer-Policy

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

Beperkt hoeveel van uw URL's aan andere sites wordt doorgegeven wanneer bezoekers op links klikken. Dat is belangrijk als URL's ordernummers, tokens of zoektermen bevatten.

Permissions-Policy

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

Schakelt browserfuncties uit die uw site niet gebruikt, zodat een geïnjecteerd script ze niet kan opvragen.

Ook cookies hebben de juiste attributen nodig

Sessiecookies horen te worden gezet met Secure (alleen HTTPS), HttpOnly (niet leesbaar vanuit JavaScript) en SameSite=Lax of Strict:

Set-Cookie: session=...; Secure; HttpOnly; SameSite=Lax; Path=/

Controleer ook het Domain van de cookie. Een cookie voor .yourcompany.com is leesbaar voor elk subdomein, en dat wordt een probleem als een ervan ooit wordt overgenomen via een verweesd DNS-record.

Headers om te verwijderen of niet meer te gebruiken

• Server en X-Powered-By met versienummers, zoals Apache/2.4.41 of PHP/7.4.3. Ze vertellen iedereen precies naar welke software en versie hij moet zoeken. OWASP raadt aan X-Powered-By te verwijderen en Server niets te laten prijsgeven.
• X-XSS-Protection. MDN markeert deze header als verouderd en niet-standaard en merkt op dat hij problemen kan veroorzaken op sites die verder veilig zijn. OWASP raadt aan hem niet te zetten, of X-XSS-Protection: 0 te zetten, en op CSP te vertrouwen.
• Expect-CT. OWASP raadt af hem te gebruiken en adviseert hem uit bestaande configuraties te halen.

Waar u ze instelt

Stel headers in op één plek die elk antwoord dekt: de webserver (nginx add_header ... always;, Apache Header always set), het CDN of de headerinstellingen van het hostingplatform. Het sleutelwoord always in nginx is belangrijk: zonder dat woord worden headers alleen toegevoegd aan succesvolle antwoorden en redirects, niet aan foutpagina's.

Korte checklist

• Voer curl -sI uit op elke hostnaam die u bezit.
• Voeg HSTS, X-Content-Type-Options, Referrer-Policy, Permissions-Policy en frame-ancestors toe.
• Rol een volledige CSP eerst uit in rapportagemodus.
• Zet Secure, HttpOnly en SameSite op sessiecookies.
• Haal versienummers uit Server en X-Powered-By, en schrap X-XSS-Protection en Expect-CT.
• Controleer opnieuw na elke wijziging van server, CDN of platform.

Nu u toch in de serverconfiguratie zit: controleer ook dat er geen blootgestelde .env-, .git- of back-upbestanden worden geserveerd.

De rol van Datahorses

Datahorses bewaakt uw websites elke dag van buitenaf en controleert wat browsers en aanvallers ontvangen: ontbrekende security headers, cookies zonder Secure, HttpOnly of SameSite, servers die hun versies verraden en gemengde HTTP-inhoud op HTTPS-pagina's. We gaan uw systemen niet binnen en hebben geen toegang nodig, en bij elke bevinding hoort de exacte configuratiewijziging voor uw ontwikkelaar. Bekijk de volledige lijst van wat wij bewaken of vraag een offerte aan.