Security headers voor websites: beveiligingsheaders correct instellen

Kort gezegd: Security headers zijn instructies van de webserver aan de browser die bezoekers beschermen tegen aanvallen als cross-site scripting, clickjacking en onversleutelde verbindingen. De belangrijkste zijn HSTS, Content Security Policy, X-Content-Type-Options, bescherming tegen vreemde frames, Referrer-Policy en Permissions-Policy. Ze zijn een zinvolle verharding, maar vervangen geen updates op de server.

Wat security headers wel en niet doen

Bij elke pagina-aanroep stuurt de webserver naast de inhoud ook headers mee. Enkele daarvan sturen beveiligingsfuncties van de browser aan. Daarmee is bijvoorbeeld vast te leggen dat een pagina alleen via HTTPS wordt geladen of dat de browser geen scripts van vreemde domeinen uitvoert.

Voor exploitanten is de duiding belangrijk: headers beschermen in de eerste plaats de bezoekers, bijvoorbeeld tegen het onderscheppen van sessies of tegen gemanipuleerde formulieren. Ze dichten geen kwetsbaarheden op de server. Een zwakke plek in PHP, in het CMS of in een extensie blijft bestaan, hoe goed de headers ook zijn ingesteld. In samenspel met nette code beperken ze echter de gevolgen van veel fouten aanzienlijk.

De belangrijkste security headers in een overzicht

HSTS moet u pas instellen wanneer alle subdomeinen betrouwbaar via HTTPS bereikbaar zijn. De browser onthoudt de instructie gedurende de opgegeven tijd; een fout is dan niet meteen terug te draaien. Begin eventueel met een korte looptijd en verhoog die na geslaagde tests. De extra optie preload neemt het domein blijvend op in lijsten van de browserfabrikanten en mag alleen na zorgvuldige controle worden ingesteld.

Headers zijn bovendien niet de enige plek waar de browser bescherming biedt. Cookies moeten de attributen Secure, HttpOnly en SameSite dragen, zodat sessies niet via onversleutelde verbindingen of scripts worden onderschept. Hoe u dat in PHP instelt, beschrijft de gids over sessies.

Security headers instellen in Nginx

In Nginx horen de headers in het server-blok van de betreffende website. De toevoeging always zorgt ervoor dat ze ook bij foutpagina's worden verstuurd.

server {
    # ...
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" 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 "camera=(), microphone=(), geolocation=()" always;
    add_header Content-Security-Policy-Report-Only "default-src 'self'; img-src 'self' data:; object-src 'none'; base-uri 'self'; frame-ancestors 'self'; form-action 'self'" always;

    server_tokens off;
}

Een eigenaardigheid van Nginx: stelt een location-blok eigen add_header-instructies in, dan worden de headers uit het server-blok daar niet overgenomen. Controleer daarom ook subpagina's en statische bestanden. Verdere verharding voor deze combinatie beschrijft Nginx met PHP-FPM beveiligen.

Security headers instellen in Apache

Onder Apache hebt u de module mod_headers nodig. De instructies horen in de VirtualHost of, als daarop geen toegang is, in de .htaccess.

<IfModule mod_headers.c>
    Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
    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 "camera=(), microphone=(), geolocation=()"
    Header always set Content-Security-Policy-Report-Only "default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'self'"
</IfModule>

ServerTokens Prod
ServerSignature Off

ServerTokens en ServerSignature horen in de hoofdconfiguratie. Ze voorkomen dat de server zijn exacte versie in antwoorden en foutpagina's noemt. In de php.ini bereikt u hetzelfde voor PHP met expose_php = Off.

Content Security Policy stapsgewijs invoeren

De Content Security Policy is de meest werkzame, maar ook de meest veeleisende header. Ze legt vast uit welke bronnen scripts, stylesheets, afbeeldingen, lettertypen en frames mogen worden geladen. Wordt een binnengebracht script van een vreemd domein nageladen, dan blokkeert de browser het.

Moderne websites sluiten vaak analysehulpmiddelen, betaalaanbieders, kaartdiensten of video's in. Een te strikt beleid legt dan functies plat. Ga daarom in stappen te werk:

• Begin met Content-Security-Policy-Report-Only. De browser meldt overtredingen in de ontwikkelaarsconsole of aan een verzameladres, maar blokkeert niets.
• Alle benodigde bronnen inventariseren en gericht vrijgeven, in plaats van algemene jokertekens te gebruiken.
• Inline-scripts stapsgewijs naar bestanden verplaatsen of voorzien van nonces, zodat 'unsafe-inline' achterwege kan blijven.
• Pas na een testfase zonder onverwachte meldingen overschakelen naar Content-Security-Policy.

Headers controleren en typische fouten vermijden

Controleer na elke wijziging of de headers daadwerkelijk aankomen. Dat gaat zonder extra hulpmiddelen met curl:

# Configuratie testen en opnieuw laden
nginx -t && systemctl reload nginx

# Headers van de startpagina en van een statisch bestand tonen
curl -sI https://www.example.de/ | grep -iE 'strict|content-security|x-content|x-frame|referrer|permissions|server'
curl -sI https://www.example.de/favicon.ico | grep -iE 'strict|x-content'

Typische fouten zijn dubbel ingestelde headers wanneer webserver en toepassing dezelfde headers sturen, een voorgeschakeld CDN dat headers verwijdert of overschrijft, en headers die alleen op de startpagina verschijnen maar niet bij doorverwijzingen of foutpagina's. Controleer bovendien na updates van het CMS of van beveiligingsextensies of de headers zijn veranderd.

Bepaal daarom één plek waar de headers worden onderhouden, het best de webserver of de voorgeschakelde dienst. Veel CMS-extensies bieden eveneens instellingen voor beveiligingsheaders. Dat is gemakkelijk, maar leidt snel tot dubbele of tegenstrijdige gegevens als bovendien de server headers instelt. Voor afzonderlijke tests lenen zich ook de ontwikkelaarshulpmiddelen van de browser: op het tabblad Netwerk ziet u bij elk verzoek de antwoordheaders en de console toont overtredingen van de Content Security Policy.

Hoe helpt PHP SOS concreet?

• We controleren de actuele headers van al uw websites, ook achter CDN en proxy, en tonen gaten en tegenstrijdigheden.
• We stellen de headers centraal in de webserver in binnen de serververharding en testen startpagina, subpagina's en foutpagina's.
• We voeren de Content Security Policy in de report-only-modus in, analyseren de meldingen en schakelen haar na overleg in.
• Waar codewijzigingen niet direct mogelijk zijn, vullen we de bescherming aan met WAF-regels en virtuele patching.

Veelgestelde vragen

Bronnen

• OWASP Cheat Sheet Series (HTTP Headers)
• OWASP Top 10
• BSI: aanbevelingen voor webservers (Duitse federale dienst voor informatiebeveiliging)