Security headers bij Cloudflare & reverse proxies: wie is de baas?

In een moderne infrastructuur communiceert een browser zelden direct met de applicatieserver. Er zitten vaak meerdere lagen tussen: een CDN zoals Cloudflare, een caching layer zoals Varnish, en een webserver als Nginx. Deze gelaagdheid creëert een 'ownership'-probleem voor HTTP-headers.

Strategisch belang

Conflicterende configuraties ondermijnen je beveiliging. Als je origin server een strikte CSP stuurt, maar je Cloudflare-configuratie deze overschrijft met een zwakkere variant, is je applicatie alsnog kwetsbaar. Dit resulteert niet alleen in een lagere score op headeraudit.nl, maar in een daadwerkelijk beveiligingsrisico.

De rolverdeling: Origin vs. Edge

Voor een correcte implementatie moet je de volgorde van executie begrijpen: Cloudflare (Edge) → Varnish (Cache) → Nginx (Reverse Proxy) → App Server (Origin).

Veelgemaakte architecturale fouten:

Dubbele headers — Zowel Nginx als Cloudflare voegen een X-Frame-Options header toe. Sommige browsers negeren de header volledig als deze dubbel en inconsistent voorkomt.
Stripping — Een tussenliggende proxy stript 'onbekende' headers, waardoor je zorgvuldig geconfigureerde CSP nooit de browser bereikt.
Overwrite-conflicten — Cloudflare Transform Rules die blindelings headers toevoegen zonder te controleren of de origin deze al correct heeft gezet.

Configuratie-oplossingen voor de Edge

Wanneer je headers op de Edge wilt beheren, gebruik dan bij Cloudflare de specifieke route: Rules → Transform Rules → Response Header Modification. Hier kun je kiezen om een header te 'Set' (overschrijven) of 'Add' (toevoegen indien niet aanwezig).

Indien je Nginx als reverse proxy gebruikt, moet je de controle behouden over wat de upstream server stuurt:

Nginx als Reverse Proxy

location / {
    proxy_pass http://upstream_app;

    # Voorkom dubbele headers door de upstream variant te verbergen
    proxy_hide_header Content-Security-Policy;

    # Forceer de centrale security policy
    add_header Content-Security-Policy "default-src 'self';" always;
    add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
}

Checklist voor ownership-verificatie:

Test de origin direct: curl -I -H "Host: domein.nl" http://localhost op de server zelf.
Controleer de keten: verifieer of Varnish of Nginx headers manipuleert met proxy_hide_header.
Final audit: controleer via de browser dev-tools of de ontvangen headers overeenkomen met je centrale security policy.

Security headers zijn geen "set and forget"-configuratie, maar een integraal onderdeel van je infrastructuur. Door CSP en HSTS als basis te nemen, legacy headers zoals XFO te moderniseren en expliciet ownership te definiëren in je proxy-keten, creëer je een robuuste verdediging.

Test je site nu