HTTP-beveiligingsheaders
Controleer of uw website de juiste HTTP-beveiligingsheaders heeft ingesteld.
Zo werkt de header-check
De tool stuurt een gewoon HTTPS-GET-verzoek naar de ingevoerde URL en leest de response-headers - dezelfde headers die elke browser ontvangt. Er wordt niets uit de pagina-inhoud geparseerd; security-headers zitten volledig in de HTTP-respons.
Vervolgens zoeken we naar de headers die de beveiliging aan browserzijde sturen: Strict-Transport-Security (HSTS), Content-Security-Policy (CSP), X-Frame-Options, X-Content-Type-Options en Referrer-Policy. Elke aanwezige header telt mee voor de score, en ontbrekende worden vermeld met uitleg over het risico dat openblijft.
Omdat de check redirects volgt, weerspiegelt het resultaat de uiteindelijke URL. Als uw site doorverwijst van HTTP naar HTTPS of van het apex-domein naar www, horen de getoonde headers bij de bestemming.
Zo leest u de resultaten
De score is een snelle indicatie, geen certificering. Wat in de praktijk telt:
- HSTS - vertelt browsers om voor uw domein altijd HTTPS te gebruiken. Een max-age van minstens een half jaar is gangbaar; voeg includeSubDomains alleen toe als elk subdomein HTTPS serveert.
- CSP - de sterkste verdediging tegen XSS, maar ook de lastigste om te schrijven. Zelfs een basaal beleid dat scriptbronnen beperkt is een grote verbetering ten opzichte van geen beleid.
- X-Content-Type-Options: nosniff en X-Frame-Options (of de CSP-directive frame-ancestors) - goedkope one-liners tegen MIME-sniffing en clickjacking.
Veelvoorkomende problemen
Header geconfigureerd, maar gemeld als ontbrekend. Een reverse proxy of CDN voor uw applicatie kan headers strippen of overschrijven. Vergelijk de respons via curl -I rechtstreeks tegen de origin en tegen de publieke URL om te vinden welke laag hem laat vallen.
CSP aanwezig, maar zonder effect. Content-Security-Policy-Report-Only logt schendingen zonder iets te blokkeren. Dat is handig voor tests, maar biedt geen bescherming - schakel over naar de afdwingende header zodra uw report-log schoon is.
Verschillende routes geven verschillende headers terug. Headers die in applicatie-middleware zijn gezet, gelden mogelijk niet voor statische bestanden die de webserver direct uitlevert, of voor foutpagina's. Test ook een statische asset-URL en een 404-pagina.
Veelgestelde vragen
Welke security-headers zou elke website moeten hebben?
Een redelijke basis: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options: nosniff, Referrer-Policy en framebescherming via X-Frame-Options of CSP frame-ancestors. API's profiteren daarnaast van Cache-Control: no-store op gevoelige responses.
Is de header X-XSS-Protection nog nodig?
Nee. Moderne browsers hebben de XSS-auditor die hij aanstuurde verwijderd, en in oude browsers kon de header zelfs kwetsbaarheden introduceren. Gebruik in plaats daarvan een strikte Content-Security-Policy.
Beschermt HSTS ook het allereerste bezoek?
Niet uit zichzelf - de browser leert de regel pas uit de eerste HTTPS-respons. Om het eerste bezoek af te dekken, meldt u uw domein aan bij de HSTS-preloadlijst (hstspreload.org) en gebruikt u de preload-directive samen met includeSubDomains.
Kan een verkeerde header mijn site breken?
Ja, twee klassiekers: een te strikte CSP blokkeert uw eigen scripts of inline styles, en HSTS met includeSubDomains breekt elk subdomein dat nog op gewoon HTTP draait. Rol CSP eerst uit in report-only-modus en begin HSTS met een korte max-age.
Volg headerwijzigingen continu
ePulz.io waarschuwt u wanneer een header verandert (bijvoorbeeld na een deployment die per ongeluk CSP heeft verwijderd).
Begin met ePulz.io →Over deze tool
Beveiligingsheaders vertellen de browser hoe je bezoekers beschermd moeten worden. Deze audit controleert of HSTS, Content-Security-Policy, X-Frame-Options, X-Content-Type-Options en Referrer-Policy daadwerkelijk aanwezig zijn en geeft het resultaat een score, zodat je clickjacking- en MIME-sniffing-gaten na een deploy kunt opsporen.