HTTP Headers Check

Wat zijn HTTP headers?

HTTP headers zijn metadata die bij elk HTTP request en response worden verzonden tussen de browser en de webserver. Ze bevatten essentiële informatie over beveiliging, caching, compressie en hoe de browser de content moet verwerken. Met onze gratis HTTP headers check tool kun je alle headers van elke website analyseren en krijg je direct inzicht in mogelijke beveiligingsrisico's en optimalisatiemogelijkheden.

Headers zijn onzichtbaar voor bezoekers maar spelen een cruciale rol in de werking van het moderne web. Elk keer dat je browser een website opvraagt, worden tientallen headers uitgewisseld. De browser stuurt request headers (zoals User-Agent, Accept-Language) en de server antwoordt met response headers (zoals Content-Type, Cache-Control, security headers). Deze communicatie bepaalt hoe content wordt weergegeven, gecached en beveiligd.

Er zijn verschillende categorieën headers: security headers die beschermen tegen aanvallen, caching headers die performance verbeteren, content headers die het type en encoding specificeren, en CORS headers die cross-origin requests beheren. Een grondige HTTP headers check geeft je inzicht in alle categorieën en toont waar verbeteringen mogelijk zijn.

Waarom zijn security headers belangrijk?

Security headers vormen een cruciale verdedigingslinie tegen veelvoorkomende webaanvallen. Ze fungeren als een extra beveiligingslaag bovenop je applicatiecode en beschermen zowel je website als je bezoekers. Zelfs met perfect beveiligde code kunnen ontbrekende security headers je kwetsbaar maken voor aanvallen. Onze HTTP headers check tool controleert alle essentiële security headers en geeft je concrete aanbevelingen.

Security headers beschermen je website en bezoekers tegen:

• XSS-aanvallen (Cross-Site Scripting) – via Content-Security-Policy (CSP) voorkom je dat kwaadaardige scripts worden uitgevoerd
• Clickjacking – via X-Frame-Options bescherm je tegen onzichtbare iframes die clicks onderscheppen
• Man-in-the-middle aanvallen – via HSTS forceer je versleutelde HTTPS-verbindingen
• MIME-sniffing aanvallen – via X-Content-Type-Options voorkom je dat browsers content-types raden
• Cross-origin attacks – via COOP en CORP headers isoleer je je website van andere origins
• Referrer leaks – via Referrer-Policy beheer je welke informatie wordt doorgestuurd
• Feature misbruik – via Permissions-Policy beperk je toegang tot gevoelige browser APIs

Zonder de juiste security headers is je website kwetsbaar voor aanvallen, zelfs als de code zelf veilig is. Beveiligingsonderzoekers en penetratietestters controleren altijd als eerste de HTTP headers om kwetsbaarheden te identificeren. Grote tech-bedrijven zoals Google, Facebook en Microsoft hanteren strikte security header policies. Met onze tool doe je dezelfde checks als professionele security audits.

Belangrijkste security headers uitgelegd

Strict-Transport-Security (HSTS) – Deze header forceert browsers om alleen via HTTPS te verbinden met je website. Het voorkomt dat aanvallers gebruikers kunnen downgraden naar onveilig HTTP verkeer (SSL stripping attacks). Zodra een browser deze header heeft ontvangen, zal hij gedurende de opgegeven periode automatisch alle HTTP-verzoeken upgraden naar HTTPS, zelfs als de gebruiker expliciet http:// intypt. Aanbevolen configuratie: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload. De max-age geeft aan hoelang (in seconden) de browser dit moet onthouden, includeSubDomains past het toe op alle subdomeinen, en preload maakt je site geschikt voor de HSTS preload list van browsers.

Content-Security-Policy (CSP) – De krachtigste security header tegen XSS-aanvallen. CSP bepaalt welke bronnen (scripts, stylesheets, afbeeldingen, fonts) de browser mag laden en uitvoeren. Dit voorkomt dat geïnjecteerde kwaadaardige scripts worden uitgevoerd, zelfs als een aanvaller erin slaagt code in je HTML te injecteren. Een basis CSP kan eruitzien als: Content-Security-Policy: default-src 'self'; script-src 'self' 'unsafe-inline'; style-src 'self' 'unsafe-inline'. Voor maximale beveiliging vermijd je 'unsafe-inline' en gebruik je nonces of hashes.

X-Frame-Options – Voorkomt dat je website in een iframe kan worden geladen, wat clickjacking-aanvallen tegengaat. Bij clickjacking plaatst een aanvaller je site in een onzichtbare iframe over een valse interface, zodat gebruikers onbedoeld acties uitvoeren op jouw site. Gebruik X-Frame-Options: DENY om alle framing te blokkeren, of X-Frame-Options: SAMEORIGIN om alleen framing van je eigen domein toe te staan. Voor moderne browsers is Content-Security-Policy: frame-ancestors 'none' een flexibelere oplossing.

X-Content-Type-Options – Voorkomt MIME-sniffing door de browser te instrueren het opgegeven content-type te respecteren. Browsers proberen soms het content-type te "raden" als het niet duidelijk is, wat kan leiden tot security problemen. Een text/plain bestand kan bijvoorbeeld als JavaScript worden geïnterpreteerd als het executable code bevat. Gebruik altijd X-Content-Type-Options: nosniff om dit te voorkomen.

Alle security headers op een rij

Een complete overzicht van alle belangrijke security headers die je kunt implementeren voor maximale bescherming. Deze headers worden allemaal gecontroleerd door onze HTTP headers check tool:

Header	Functie	Aanbevolen waarde
Strict-Transport-Security	Forceert HTTPS verbindingen	max-age=31536000; includeSubDomains
Content-Security-Policy	Bepaalt toegestane content bronnen	default-src 'self'
X-Frame-Options	Beschermt tegen clickjacking	DENY of SAMEORIGIN
X-Content-Type-Options	Voorkomt MIME-sniffing	nosniff
Referrer-Policy	Beheert referrer informatie	strict-origin-when-cross-origin
Permissions-Policy	Controleert browser features	geolocation=(), microphone=(), camera=()
Cross-Origin-Opener-Policy	Isoleert browsing context	same-origin
Cross-Origin-Resource-Policy	Beschermt tegen cross-origin lezen	same-origin
Cross-Origin-Embedder-Policy	Vereist CORP voor embedded resources	require-corp

Content-Security-Policy in detail

Content-Security-Policy (CSP) is de meest complexe maar ook krachtigste security header. Een goed geconfigureerde CSP kan XSS-aanvallen vrijwel volledig elimineren. CSP werkt met directives die bepalen welke bronnen voor elk type content zijn toegestaan.

Belangrijkste CSP directives:

• default-src – Standaard policy voor alle resource types. Andere directives erven hiervan.
• script-src – Bepaalt welke JavaScript bronnen mogen worden geladen en uitgevoerd. Kritiek voor XSS-bescherming.
• style-src – Controleert welke stylesheets en inline styles zijn toegestaan.
• img-src – Bepaalt van welke bronnen afbeeldingen mogen worden geladen.
• font-src – Controleert toegestane font bronnen.
• connect-src – Beperkt welke URLs via fetch, XMLHttpRequest, WebSocket kunnen worden benaderd.
• frame-src – Bepaalt welke URLs in frames mogen worden geladen (vergelijkbaar met X-Frame-Options maar voor embedded content).
• media-src – Controleert bronnen voor audio en video elementen.
• object-src – Bepaalt toegestane bronnen voor <object>, <embed> en <applet> elementen.

CSP source values: Elke directive accepteert een lijst van toegestane bronnen. Je kunt gebruiken: 'self' (eigen domein), 'none' (niets toegestaan), specifieke domeinen zoals https://cdn.example.com, 'unsafe-inline' (inline scripts/styles, onveilig), 'unsafe-eval' (eval() functie, onveilig), of nonces/hashes voor specifieke inline scripts.

Nonces en hashes: Voor maximale beveiliging vermijd je 'unsafe-inline' en gebruik je in plaats daarvan nonces of hashes. Een nonce is een unieke random waarde die je genereert per request en toevoegt aan zowel de CSP header als het script tag: Content-Security-Policy: script-src 'nonce-abc123' en <script nonce="abc123">. Hashes zijn SHA-256/384/512 hashes van de exacte script content: script-src 'sha256-xyz...'.

Report-URI en reporting: CSP kan schendingen rapporteren naar een endpoint: report-uri /csp-report of met de modernere report-to directive. Dit helpt je om te monitoren of legitieme content wordt geblokkeerd en of er aanvalspogingen zijn. Begin altijd met Content-Security-Policy-Report-Only om te testen zonder content te blokkeren.

Performance en caching headers

Naast beveiliging analyseert onze HTTP headers check ook performance- en caching-headers die cruciaal zijn voor snelle websites:

• Content-Encoding – Controleert of compressie actief is. Moderne websites gebruiken gzip of brotli compressie om tekstbestanden (HTML, CSS, JavaScript) tot 70-80% te verkleinen. Content-Encoding: br (brotli) geeft betere compressie dan gzip maar wordt niet door alle browsers ondersteund. Content-Encoding: gzip is de veilige keuze die overal werkt. Zonder compressie laden pagina's veel trager, vooral op mobiele verbindingen.
• Cache-Control – Analyseert cache-instellingen voor optimale performance. Deze header bepaalt hoe lang browsers en CDNs content mogen cachen. Voor statische assets (CSS, JS, afbeeldingen) gebruik je Cache-Control: public, max-age=31536000, immutable voor caching van een jaar. Voor dynamische content gebruik je Cache-Control: private, max-age=0, must-revalidate. De juiste cache strategie kan je serverbelasting met 90% verminderen en laadtijden drastisch verbeteren.
• ETag – Checkt of cache-validatie is ingeschakeld. Een ETag is een unieke identifier voor een specifieke versie van een resource. Als een browser gecachete content heeft, stuurt hij de ETag mee in een If-None-Match header. Als de content niet is gewijzigd, antwoordt de server met 304 Not Modified zonder de volledige content te verzenden, wat bandbreedte bespaart.
• Vary – Bekijkt welke request headers caching beïnvloeden. Vary: Accept-Encoding vertelt caches dat zowel gecomprimeerde als ongecomprimeerde versies opgeslagen moeten worden. Vary: User-Agent cacht verschillende versies per browser type (vaak onnodig en inefficiënt). Voor moderne responsive sites is Vary: Accept-Encoding vaak voldoende.
• Last-Modified – Geeft aan wanneer content voor het laatst is gewijzigd, werkt samen met If-Modified-Since voor cache-validatie.

Juiste caching-headers kunnen je website aanzienlijk sneller maken, serverbelasting verminderen en bandbreedtekosten drastisch verlagen. Voor WordPress hosting of andere CMS-platforms zijn goede cache headers essentieel voor performance.

Hoe verbeter je je security score?

Na een HTTP headers check geeft onze tool een score per categorie en concrete aanbevelingen. Je kunt security headers op verschillende manieren implementeren:

1. Webserver configuratie – De meest efficiënte methode is headers instellen op webserver niveau. Voor Apache (.htaccess), Nginx of IIS kun je headers toevoegen die voor alle requests gelden. Dit is sneller dan applicatie-niveau headers omdat de webserver ze direct toevoegt zonder PHP of andere applicatiecode uit te voeren. Voor VPS hosting heb je volledige controle over de webserver configuratie.

2. Applicatie code – In PHP, Node.js, Python of andere talen kun je headers programmatisch toevoegen. Dit geeft meer flexibiliteit (bijvoorbeeld verschillende CSP policies per pagina) maar is iets langzamer. Voor WordPress sites kun je headers toevoegen via functions.php of security plugins.

3. CDN/Proxy niveau – Services zoals Cloudflare, AWS CloudFront of andere CDN's kunnen headers toevoegen of aanpassen. Dit is ideaal voor sites die al een CDN gebruiken. Cloudflare heeft bijvoorbeeld eenvoudige "Transform Rules" om headers toe te voegen.

4. CMS plugins – Voor WordPress zijn er uitstekende security plugins die headers automatisch configureren, zoals Really Simple SSL, Security Headers, of All In One WP Security. Deze plugins bieden een gebruiksvriendelijke interface zonder dat je configuratiebestanden hoeft te bewerken.

Begin met de essentiële headers (HSTS, CSP, X-Frame-Options, X-Content-Type-Options) en breid daarna uit met andere security headers zoals Referrer-Policy en Permissions-Policy. Test altijd grondig na het toevoegen van headers, vooral CSP kan legitieme functionaliteit blokkeren als het te strikt is geconfigureerd.

HTTP headers voor WordPress

WordPress sites hebben specifieke overwegingen voor HTTP headers. Standaard stuurt WordPress minimale security headers, dus je moet deze zelf toevoegen. Er zijn drie methoden om headers toe te voegen aan WordPress:

Methode 1: Via .htaccess (Apache) – Als je site op Apache draait (de meeste webhosting pakketten), voeg dan deze regels toe aan je .htaccess bestand in de WordPress root:

<IfModule mod_headers.c>
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  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=(), microphone=(), camera=()"
  Header always set Content-Security-Policy "default-src 'self'; script-src 'self' 'unsafe-inline' 'unsafe-eval'; style-src 'self' 'unsafe-inline'"
</IfModule>

Let op: deze CSP is relatief permissief met 'unsafe-inline' en 'unsafe-eval' omdat WordPress en veel plugins inline scripts gebruiken. Voor een strengere CSP moet je mogelijk plugin code aanpassen.

Methode 2: Via wp-config.php – Je kunt headers toevoegen in wp-config.php (voeg dit toe voor de "That's all, stop editing!" regel):

header('Strict-Transport-Security: max-age=31536000; includeSubDomains');
header('X-Frame-Options: SAMEORIGIN');
header('X-Content-Type-Options: nosniff');
header('Referrer-Policy: strict-origin-when-cross-origin');

Methode 3: Via functions.php – In je theme's functions.php (of een custom plugin), voeg je deze functie toe:

function add_security_headers() {
  header('Strict-Transport-Security: max-age=31536000; includeSubDomains');
  header('X-Frame-Options: SAMEORIGIN');
  header('X-Content-Type-Options: nosniff');
}
add_action('send_headers', 'add_security_headers');

WordPress plugins: Voor gebruiksvriendelijkere configuratie kun je plugins gebruiken zoals "HTTP Headers" (door Dimitar Ivanov) of "Security Headers" die een GUI bieden voor header configuratie. Really Simple SSL voegt ook automatisch enkele security headers toe na activatie. Voor WordPress hosting bij Theory7 kun je ook contact opnemen met support voor hulp bij het configureren van headers.

HTTP headers voor Apache en Nginx

De configuratie van HTTP headers verschilt tussen Apache en Nginx webservers. Beide zijn krachtige opties, maar de syntax is verschillend.

Apache configuratie (.htaccess of httpd.conf):

Voor Apache gebruik je de mod_headers module. In .htaccess of je virtuele host configuratie voeg je toe:

<IfModule mod_headers.c>
  # Security headers
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
  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=(), microphone=(), camera=()"
  Header always set Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self'"

  # Performance headers
  Header always set Cache-Control "public, max-age=31536000, immutable" "expr=%{REQUEST_URI} =~ m#\.(jpg|jpeg|png|gif|ico|css|js|woff|woff2)$#"
  Header always set Cache-Control "no-cache, no-store, must-revalidate" "expr=%{REQUEST_URI} =~ m#\.(html|php)$#"
</IfModule>

Zorg ervoor dat mod_headers is ingeschakeld: a2enmod headers en herstart Apache.

Nginx configuratie (nginx.conf of server block):

Voor Nginx voeg je headers toe in je server block of location context:

server {
  # Security headers
  add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
  add_header X-Frame-Options "SAMEORIGIN" always;
  add_header X-Content-Type-Options "nosniff" always;
  add_header Referrer-Policy "strict-origin-when-cross-origin" always;
  add_header Permissions-Policy "geolocation=(), microphone=(), camera=()" always;
  add_header Content-Security-Policy "default-src 'self'; script-src 'self'; style-src 'self' 'unsafe-inline'; img-src 'self' data: https:; font-src 'self' data:; connect-src 'self'" always;

  # Static assets caching
  location ~* \.(jpg|jpeg|png|gif|ico|css|js|woff|woff2)$ {
    add_header Cache-Control "public, max-age=31536000, immutable";
    expires 1y;
  }

  # Dynamic content
  location ~* \.(html|php)$ {
    add_header Cache-Control "no-cache, no-store, must-revalidate";
  }
}

Na wijzigingen test je de configuratie met nginx -t en herlaad je met nginx -s reload. Het always keyword zorgt ervoor dat headers ook worden toegevoegd bij error responses (4xx, 5xx).

Voor beide webservers geldt: test grondig na het toevoegen van headers met onze HTTP headers check tool en controleer of je site nog correct functioneert.

HTTP response codes

HTTP response codes (status codes) worden via headers verzonden en geven aan of een request succesvol was. Onze tool toont de status code bij elke check. Veelvoorkomende codes:

Code	Betekenis	Uitleg
200	OK	Verzoek succesvol, content wordt teruggestuurd
301	Moved Permanently	Permanente redirect, belangrijk voor SEO. Browser en zoekmachines onthouden de nieuwe URL.
302	Found (Temporary Redirect)	Tijdelijke redirect, zoekmachines blijven de originele URL indexeren
304	Not Modified	Content niet gewijzigd sinds laatste request, browser gebruikt cached versie (bespaart bandbreedte)
403	Forbidden	Toegang geweigerd, zelfs met authenticatie. Server begrijpt request maar weigert uitvoering.
404	Not Found	Pagina of resource bestaat niet. Controleer DNS configuratie en server paths.
500	Internal Server Error	Algemene serverfout. Controleer server logs voor details.
502	Bad Gateway	Server ontving ongeldig antwoord van upstream server (bijv. PHP-FPM of backend service)
503	Service Unavailable	Server tijdelijk overbelast of in onderhoud. Vaak met Retry-After header.

De status code zit in de eerste response header regel, bijvoorbeeld HTTP/1.1 200 OK. Bij redirects (301/302) wordt de nieuwe locatie aangegeven via de Location header. Bij errors tonen servers vaak een Content-Type: text/html header met een error pagina. Voor SEO zijn correcte status codes cruciaal – gebruik 301 voor permanente redirects en zorg dat verwijderde pagina's 404 (niet 200) teruggeven.

CORS headers uitgelegd

CORS (Cross-Origin Resource Sharing) headers bepalen of een website resources mag laden van een ander domein. Browsers blokkeren cross-origin requests standaard om veiligheidsredenen. CORS headers geven expliciet toestemming.

Access-Control-Allow-Origin – De belangrijkste CORS header. Bepaalt welke origins toegang hebben tot je resources. Access-Control-Allow-Origin: * staat alle origins toe (gevaarlijk voor gevoelige APIs), Access-Control-Allow-Origin: https://example.com staat alleen dat specifieke domein toe. Voor APIs die vanuit browsers worden aangeroepen (bijv. AJAX requests) moet deze header correct zijn ingesteld.

Access-Control-Allow-Methods – Geeft aan welke HTTP methoden zijn toegestaan: Access-Control-Allow-Methods: GET, POST, PUT, DELETE. Standaard zijn alleen GET en POST toegestaan voor simple requests.

Access-Control-Allow-Headers – Specificeert welke request headers de client mag sturen: Access-Control-Allow-Headers: Content-Type, Authorization. Nodig voor custom headers of authentication tokens.

Access-Control-Allow-Credentials – Bepaalt of cookies en authentication headers mogen worden meegestuurd: Access-Control-Allow-Credentials: true. Als dit true is, mag Access-Control-Allow-Origin niet * zijn.

Preflight requests: Voor "non-simple" requests (bijv. PUT, DELETE, of custom headers) stuurt de browser eerst een OPTIONS request (preflight) om te checken of de request is toegestaan. De server moet dan antwoorden met de juiste CORS headers. Een preflight response ziet er zo uit:

HTTP/1.1 204 No Content
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET, POST, PUT, DELETE
Access-Control-Allow-Headers: Content-Type, Authorization
Access-Control-Max-Age: 86400

De Access-Control-Max-Age header geeft aan hoelang (in seconden) het preflight response mag worden gecached, wat performance verbetert. Voor web APIs en SSL-beveiligde endpoints zijn correcte CORS headers essentieel.

HTTP/2 en HTTP/3 headers

Moderne protocollen HTTP/2 en HTTP/3 behandelen headers efficiënter dan HTTP/1.1, maar de header namen en waarden blijven grotendeels hetzelfde. Onze HTTP headers check werkt met alle HTTP versies.

HTTP/2 verbeteringen: HTTP/2 introduceert HPACK header compressie, wat headers aanzienlijk verkleint. Headers worden gecodeerd met Huffman encoding en een statische/dynamische tabel van veelvoorkomende headers. Dit bespaart bandbreedte omdat Content-Type: text/html bijvoorbeeld wordt gecodeerd als een enkele byte in plaats van 24 bytes. HTTP/2 ondersteunt ook multiplexing, waardoor meerdere requests dezelfde verbinding delen en header overhead verder wordt gereduceerd.

Pseudo-headers in HTTP/2: HTTP/2 gebruikt speciale pseudo-headers die beginnen met een dubbele punt: :method, :path, :scheme, :authority. Deze vervangen de eerste regel van HTTP/1.1 requests (GET /path HTTP/1.1). Voor developers zijn deze meestal onzichtbaar omdat libraries dit automatisch afhandelen.

HTTP/3 en QUIC: HTTP/3 bouwt voort op HTTP/2 maar gebruikt QUIC in plaats van TCP als transport protocol. Headers werken hetzelfde als HTTP/2, maar QPACK (een verbeterde versie van HPACK) biedt nog betere compressie en is beter bestand tegen packet loss. HTTP/3 vereist UDP in plaats van TCP, wat latency vermindert omdat er geen TCP handshake nodig is.

Server Push (HTTP/2): HTTP/2 ondersteunt server push, waarbij de server proactief resources stuurt voordat de browser erom vraagt. Dit werkt via de Link header met rel=preload: Link: </style.css>; rel=preload; as=style. Server push is experimenteel en wordt niet door alle CDNs ondersteund. HTTP/3 heeft push verwijderd ten gunste van Early Hints (HTTP 103).

Migratie overwegingen: Bij migratie naar HTTP/2 of HTTP/3 blijven je security headers, caching headers en CORS headers identiek werken. De protocollen zijn backwards compatible op header niveau. Wel moet je SSL/TLS certificaten correct configureren, want HTTP/2 en HTTP/3 vereisen HTTPS. Voor VPS of dedicated servers moet je nginx versie 1.9.5+ of Apache 2.4.17+ gebruiken voor HTTP/2 support.

Controleer welk protocol je site gebruikt met onze tool – de HTTP versie wordt weergegeven in de response headers. HTTP/2 en HTTP/3 kunnen laadtijden met 20-50% verbeteren, vooral voor sites met veel kleine resources.