Webbeveiliging

HTTP-beveiligingsheaders: definitie

Definitie

HTTP-beveiligingsheaders zijn instructies die de server met elke pagina meestuurt en die de browser toepast: HTTPS afdwingen, weergave in een extern frame verbieden, de toegestane scripts beperken of de doorgegeven informatie inperken. Ze beschermen de bezoekers, zonder de lekken van de site zelf te verhelpen.

HTTP-beveiligingsheaders, Webbeveiliging

Elk antwoord van een webserver begint met headers die de bezoeker niet ziet: inhoudstype, cache, cookies. Sommige daarvan dienen alleen de beveiliging. Ze verhelpen geen enkel lek in de site, maar vragen de browser riskant gedrag te weigeren: de pagina tonen in het frame van een andere site, het type van een bestand raden, een onbekend script laden of terugvallen op HTTP. De bescherming geldt dus voor de bezoekers en voor de manier waarop je pagina's bij hen worden weergegeven.

De belangrijkste beveiligingsheaders

HeaderFunctieGangbare waarde
Strict-Transport-SecurityDwingt HTTPS af bij volgende bezoekenmax-age=31536000
Content-Security-PolicySomt de toegestane bronnen voor scripts, stijlen en frames opPer site op te bouwen
X-Frame-OptionsVerbiedt weergave in een extern frameSAMEORIGIN of DENY
X-Content-Type-OptionsVerbiedt de browser het type van een bestand te radennosniff
Referrer-PolicyBeperkt het adres dat aan gelinkte sites wordt doorgegevenstrict-origin-when-cross-origin
Permissions-PolicySchakelt gevoelige browser-API's uitcamera=(), microphone=(), geolocation=()

Twee ervan verdienen een eigen definitie: HSTS, dat HTTPS vastzet, en de Content Security Policy, de doeltreffendste header tegen een XSS-lek maar ook de lastigste om goed in te stellen. X-Frame-Options en de CSP-directive frame-ancestors beschermen tegen clickjacking.

Tabel in drie kolommen: headers met weinig risico op problemen (nosniff, X-Frame-Options, Referrer-Policy, Permissions-Policy), headers om eerst te testen (HSTS en CSP, in report-only-modus en daarna stapsgewijs), headers die je niet meer verstuurt (X-XSS-Protection, Expect-CT, Feature-Policy, X-Powered-By)
De nuttige headers, de headers die een testfase vragen en de headers die weg mogen.

Headers die je niet meer verstuurt

De OWASP-cheatsheet over HTTP-headers raadt X-XSS-Protection af, omdat die lekken kan veroorzaken op sites die in orde zijn (weglaten of op 0 zetten), en ook Expect-CT, die je moet verwijderen. Feature-Policy is vervangen door Permissions-Policy. Omgekeerd raadt OWASP aan X-Powered-By te verwijderen en Server zo weinig mogelijk te laten vertellen: die headers verraden de versie van PHP of van de server en maken fingerprinting makkelijker.

Video: “HTTP Security Headers Explained - What are security headers and how do I implement them?” (Halo Security, in het Engels)

Voor WordPress

WordPress verstuurt al X-Frame-Options: SAMEORIGIN en frame-ancestors 'self' in de beheeromgeving en op de inlogpagina, via de functie send_frame_options_header(). De openbare pagina's krijgen standaard geen van deze headers. Je kunt ze op drie plekken toevoegen:

  • De server: Header always set in een .htaccess onder Apache of LiteSpeed, add_header ... always in Nginx. Dat is de volledigste oplossing, omdat die ook statische bestanden en gecachete pagina's dekt.
  • Het CDN: regels die het antwoord aanpassen, handig als de site achter een proxy staat.
  • PHP of een plugin: de action send_headers, nuttig zonder toegang tot de configuratie, maar afwezig in antwoorden die niet via WordPress lopen.

Controleer het resultaat daarna met curl -I https://jouw-site.nl/ of het tabblad Netwerk van de browser, nadat je de caches hebt geleegd. Onze gids over HTTP-beveiligingsheaders voor WordPress geeft startwaarden en configuratievoorbeelden; het artikel over wat Google meeweegt zet hun (kleine) rol in SEO op een rij.

Veelgemaakte fouten

  • Een header op twee plekken toevoegen (server en plugin) met verschillende waarden.
  • always vergeten: zonder die toevoeging zetten Apache en Nginx de header niet op foutpagina's.
  • Een perfecte score op een auditprogramma nastreven met een strikte CSP die de editor of de betaling breekt.

In WP Masquerade verstuurt de gratis versie nosniff vanaf het eerste niveau van de module Hardening, en beheert de Pro-versie de beveiligingsheaders vanuit de beheeromgeving, met een knop die de werkelijk ontvangen headers toont. Een pagina die door een cache ervoor wordt geserveerd, kan ze echter missen: voor een strikt beleid blijft de serverconfiguratie het veiligst.

Verder lezen

  • Artikel Zo stel je HTTP-beveiligingsheaders in op WordPress: CSP, HSTS en de rest
  • Artikel HTTPS, HSTS en beveiligingsheaders: waar Google echt rekening mee houdt
  • Pagina Beveiligingsheaders voor WordPress

Bronnen

  1. OWASP: HTTP Security Response Headers Cheat Sheet (externe link, opent in een nieuw tabblad)
  2. MDN: Strict-Transport-Security (externe link, opent in een nieuw tabblad)
  3. WordPress Developer Resources: send_frame_options_header() (externe link, opent in een nieuw tabblad)

Alle definities

WordPress-beveiliging, zonder ruis

Eén e-mail wanneer het ertoe doet: nieuw waargenomen aanvallen, updates van de plugin en praktische gidsen. Geen spam, afmelden met één klik.

Begin gratis, stap over op Pro wanneer je eraan toe bent

De gratis versie verbergt WordPress al en verplaatst de inlogpagina. Pro voegt aliassen, tweestapsverificatie en bewaking toe.