HTTP-beveiligingsheaders: CSP, HSTS, Permissions-Policy en een complete configuratie

Het zijn geen firewall en ze repareren geen kapotte autorisatie, kwetsbare API's, SQL-injectie, gelekte inloggegevens of verouderde afhankelijkheden. Securityheaders vormen een defence-in-depth-laag: ze verkleinen het aanvalsoppervlak van de browser en beperken wat er kan gebeuren nadat een andere zwakke plek al is misbruikt.

In 2026 is het nuttig om drie categorieën te onderscheiden:

1. Basisheaders die voor de meeste websites zinvol zijn.
2. Architectuurafhankelijke headers die OAuth, betalingen, CDN's, iframes of PDF-levering kunnen breken wanneer ze zonder analyse worden gekopieerd.
3. Verouderde headers die niet ingeschakeld zouden moeten worden om louter de score van een verouderde scanner te verbeteren.

TL;DR: begin met een zorgvuldig ontworpen Content Security Policy, HSTS nadat HTTPS volledig is uitgerold, X-Content-Type-Options: nosniff, een expliciete Referrer-Policy en een terughoudende Permissions-Policy. Gebruik CSP frame-ancestors als primaire anti-framingmaatregel en behoud X-Frame-Options alleen als compatibiliteitslaag. Zet COOP, COEP en CORP pas in nadat u cross-origin-integraties hebt beoordeeld. Verwijder of schakel X-XSS-Protection, Expect-CT, HPKP en de oude Report-To-header uit.

Aanbevelingen en compatibiliteit zijn voor het laatst geverifieerd op 23 juli 2026.

De belangrijkste headers in één oogopslag

Header	Typische aanbeveling	Wat het beperkt	Overal gebruiken?
Content-Security-Policy	applicatiespecifiek beleid, bij voorkeur op basis van nonce of hash	XSS, injectie, niet-goedgekeurde resource-origins en framing	ja voor HTML, na testen
Strict-Transport-Security	max-age=31536000; includeSubDomains; voeg preload pas toe na beoordeling	HTTP-downgrade en het omzeilen van certificaatfouten	ja wanneer het hele domein HTTPS-gereed is
X-Content-Type-Options	nosniff	MIME-sniffing en sommige MIME-verwarring	ja
Referrer-Policy	strict-origin-when-cross-origin of strikter	lekken van URL-pad en query	ja
Permissions-Policy	schakel ongebruikte mogelijkheden uit, zoals camera=(), microphone=(), geolocation=()	gebruik van geselecteerde browser-API's door documenten en frames	meestal, na functietesten
CSP frame-ancestors	'none', 'self' of expliciete origins	clickjacking en ongewenste framing	ja voor HTML-documenten
X-Frame-Options	DENY of SAMEORIGIN voor compatibiliteit	framing in oudere implementaties	vaak, naast frame-ancestors
Cross-Origin-Opener-Policy	vaak same-origin, tenzij popuprelaties nodig zijn	sommige XS-Leaks en toegang via window.opener	architectuurafhankelijk
Cross-Origin-Embedder-Policy	require-corp of credentialless, alleen weloverwogen	insluiten van cross-origin-resources zonder toestemming	nee, niet automatisch
Cross-Origin-Resource-Policy	same-origin, same-site of cross-origin per resource	ongewenste no-CORS cross-origin-leesbewerkingen	resourceafhankelijk
Cache-Control	no-store voor zeer gevoelige responses; private voor gepersonaliseerde inhoud	opslag in browser- en tussenliggende caches	voor gevoelige responses
Set-Cookie	Secure; HttpOnly; SameSite=Lax/Strict naargelang	diefstal en ongepast cross-site versturen van cookies	voor sessiecookies
Reporting-Endpoints	endpoint voor CSP/COOP/COEP-rapporten	waarneembaarheid van beleid	optioneel
X-XSS-Protection	weglaten of instellen op 0	verouderd XSS-filter	niet inschakelen
Expect-CT	verwijderen	verouderd Certificate Transparency-mechanisme	nee
Public-Key-Pins	niet gebruiken	historische certificaat-pinning	nee

OWASP beschouwt responseheaders als waardevolle hardeningmaatregelen, maar benadrukt dat elke waarde moet passen bij het responsetype en de applicatiearchitectuur.

Een minimaal startpunt

Dit is een startsjabloon, geen universeel copy-paste-antwoord:

Content-Security-Policy: default-src 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none'; form-action 'self'; img-src 'self' data: https:; font-src 'self'; style-src 'self'; script-src 'self'; connect-src 'self'; upgrade-insecure-requests
Strict-Transport-Security: max-age=31536000; includeSubDomains
X-Content-Type-Options: nosniff
Referrer-Policy: strict-origin-when-cross-origin
Permissions-Policy: camera=(), microphone=(), geolocation=()
X-Frame-Options: DENY

Dit beleid blokkeert inline scripts en styles, niet-vermelde resource-origins, framing, formulieren die naar andere origins worden verzonden, toegang tot camera/microfoon/geolocatie en HTTP-navigatie nadat HSTS is opgeslagen.

Als de site externe lettertypen, analytics, kaarten, betaalwidgets, OAuth, tagmanagers, API's van derden of inline code gebruikt, moet het beleid worden aangepast.

1. Content-Security-Policy: de krachtigste en lastigste header

Content-Security-Policy bepaalt van welke bronnen de browser scripts, styles, afbeeldingen, lettertypen, frames en netwerkverbindingen mag laden. Een correcte CSP kan de impact van XSS en data-injectie aanzienlijk verkleinen, maar vervangt geen invoervalidatie, uitvoercodering en veilige DOM-API's.

Kerndirectieven

Directief	Doel	Gebruikelijke startwaarde
default-src	fallback voor resourcetypen zonder eigen directief	'self'
script-src	toegestane scripts	nonce of hashes, optioneel 'self'
style-src	toegestane styles	'self', nonce of hashes
img-src	afbeeldingen	'self' data: https:
font-src	lettertypen	'self' en expliciete CDN-origins
connect-src	Fetch, XHR, WebSocket en EventSource	uw API en expliciete endpoints
frame-src	frames die door de pagina worden ingesloten	alleen vereiste origins
frame-ancestors	welke ouders deze pagina mogen insluiten	'none' of 'self'
form-action	geldige formulierbestemmingen	'self' of expliciete endpoints
base-uri	toegestane <base>-URL's	'self' of 'none'
object-src	<object>- en <embed>-plug-ins	'none'
upgrade-insecure-requests	HTTP-subresources herschrijven naar HTTPS	geen waarde

Allowlists versus een strikte CSP

Een domein-allowlist kan fragiel worden. Een vertrouwd CDN kan veel niet-gerelateerde bestanden hosten, en een loader van derden kan dynamisch aanvullende afhankelijkheden binnenhalen. web.dev raadt een strikte CSP aan op basis van nonces of hashes; strict-dynamic laat scripts die door een vertrouwd script worden geladen het vertrouwen erven.

Voorbeeld van een nonce-beleid:

Content-Security-Policy:
  default-src 'self';
  base-uri 'self';
  object-src 'none';
  frame-ancestors 'none';
  form-action 'self';
  script-src 'nonce-{RANDOM_NONCE}' 'strict-dynamic';
  style-src 'self' 'nonce-{RANDOM_NONCE}';
  img-src 'self' data: https:;
  font-src 'self';
  connect-src 'self' https://api.example.com;
  upgrade-insecure-requests

Bijbehorende HTML:

<script nonce="{RANDOM_NONCE}">
  window.__APP_CONFIG__ = { apiUrl: "https://api.example.com" };
</script>

Een nonce moet onvoorspelbaar zijn, uniek voor elke HTML-response, aanwezig in de header en in de vertrouwde elementen, en door de server worden gegenereerd. Een constante nonce die in de configuratie is opgeslagen, biedt niet de beoogde bescherming. Voor statische pagina's die geen nieuwe waarde per request kunnen genereren, kunnen hashes praktischer zijn.

Vermijd unsafe-inline en unsafe-eval

'unsafe-inline' in script-src staat inline JavaScript toe en verzwakt de XSS-bescherming aanzienlijk. 'unsafe-eval' schakelt API's in die strings als code uitvoeren, waaronder eval() en de Function-constructor.

Voeg ze niet toe om louter consoleschendingen te onderdrukken. In plaats daarvan:

1. verplaats inline code naar externe bestanden;
2. gebruik een nonce of hash;
3. identificeer de afhankelijkheid die eval vereist;
4. zoek naar een andere build- of bibliotheekconfiguratie.

Trusted Types

Een beleid zoals:

Content-Security-Policy: require-trusted-types-for 'script'; trusted-types app-policy

kan getypeerde waarden vereisen bij geselecteerde DOM-XSS-sinks zoals innerHTML. Sinds februari 2026 is require-trusted-types-for beschikbaar in de huidige grote browsers, hoewel oudere versies het mogelijk niet ondersteunen.

Trusted Types is een geavanceerde verdediging. De applicatie moet veilige transformatiebeleidsregels definiëren, en frameworks en afhankelijkheden moeten compatibel zijn. Alleen de header toevoegen is niet voldoende.

Begin met Report-Only

Een veiligere uitrol begint met:

Content-Security-Policy-Report-Only: default-src 'self'; object-src 'none'; base-uri 'self'; frame-ancestors 'none'; report-to csp-endpoint
Reporting-Endpoints: csp-endpoint="https://example.com/security/csp-reports"

Content-Security-Policy-Report-Only rapporteert schendingen zonder resources te blokkeren, waardoor ontbrekende origins en kapotte flows kunnen worden geïdentificeerd voordat het beleid wordt afgedwongen. Reporting-Endpoints vervangt de afgeschafte Report-To-header en verdient de voorkeur voor huidige implementaties.

Een rapportage-endpoint moet limieten op payloadgrootte, rate limiting, veilige logging, uitvoercodering en een korte, doelspecifieke bewaartermijn afdwingen. CSP-rapporten kunnen URL's en resourcegegevens bevatten.

2. Strict-Transport-Security: HTTPS zonder downgradepad

HSTS vertelt de browser dat een host uitsluitend via HTTPS mag worden benaderd. Eenmaal opgeslagen, upgradet de browser toekomstige HTTP-pogingen en voorkomt dat gebruikers sommige certificaatfouten omzeilen.

Strict-Transport-Security: max-age=31536000; includeSubDomains

• max-age=31536000 slaat het beleid één jaar op.
• includeSubDomains dekt subdomeinen.
• preload geeft de intentie aan om aan de preload-lijst van de browser deel te nemen.

Begin niet met preload

Een verkeerde HSTS-implementatie kan legitieme gebruikers buitensluiten. Een oud HTTP-only-subdomein, een verlopen certificaat of een dienst van derden onder uw domein kan includeSubDomains en een lange max-age gevaarlijk maken.

Een voorzichtige uitrol kan gebruiken:

5 minutes → 1 day → 1 week → 1 month → 1 year

Test in elke fase het apex-domein, actieve subdomeinen, wildcard- en SAN-certificaten, verouderde diensten, beheerpanelen, API's en partnerendpoints.

HSTS-preload vereist een geldig certificaat, HTTP-naar-HTTPS-redirects, een voldoende lange max-age, includeSubDomains en het preload-token. Verwijdering kan weken duren omdat de lijst in browsers wordt meegeleverd.

3. X-Content-Type-Options: stop MIME-raden

X-Content-Type-Options: nosniff

Dit vertelt de browser om het opgegeven Content-Type te respecteren in plaats van een response als een ander type te herinterpreteren. Scripts en styles kunnen worden geblokkeerd wanneer hun MIME-type niet overeenkomt met wat wordt verwacht.

Het vervangt geen correcte serverconfiguratie. Responses hebben nog steeds nauwkeurige waarden nodig:

Content-Type: text/html; charset=utf-8
Content-Type: text/css; charset=utf-8
Content-Type: application/javascript; charset=utf-8
Content-Type: application/json; charset=utf-8
Content-Type: image/avif

Dit is vooral belangrijk voor uploads van gebruikers, download-endpoints, dynamisch gegenereerde bestanden, objectopslag, CDN's en foutresponses die HTML in plaats van JSON kunnen retourneren.

4. Referrer-Policy: beperk URL-lekkage

Referrer-Policy bepaalt hoeveel van de huidige pagina-URL in de Referer-header mag worden verzonden bij het opvragen van een andere resource.

Een verstandige standaardwaarde is:

Referrer-Policy: strict-origin-when-cross-origin

Het verzendt de volledige URL bij same-origin-requests, alleen de origin bij cross-origin HTTPS-requests, en geen referrer bij een HTTPS-naar-HTTP-downgrade.

Striktere alternatieven zijn onder meer:

Referrer-Policy: no-referrer

of:

Referrer-Policy: same-origin

De keuze kan invloed hebben op analytics, affiliatesystemen en betalingsproviders. Geheimen, tokens, e-mailadressen en persoonsgegevens horen sowieso niet in URL's thuis.

5. Clickjacking-bescherming: frame-ancestors en X-Frame-Options

De meest flexibele maatregel is CSP:

Content-Security-Policy: frame-ancestors 'none'

of:

Content-Security-Policy: frame-ancestors 'self' https://portal.partner.example

frame-ancestors bepaalt welke ouders een document mogen insluiten in <frame>, <iframe>, <object> of <embed>.

Voeg voor compatibiliteit toe:

X-Frame-Options: DENY

of:

X-Frame-Options: SAMEORIGIN

MDN raadt frame-ancestors aan voor moderne implementaties omdat het expressiever is. ALLOW-FROM is verouderd en kan ervoor zorgen dat huidige browsers de header negeren. X-Frame-Options moet een HTTP-header zijn; een <meta http-equiv>-versie heeft geen effect.

6. Permissions-Policy: schakel mogelijkheden uit die de site niet gebruikt

Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=()

De header regelt de toegang van een document en zijn frames tot geselecteerde browsermogelijkheden, waaronder camera, microfoon en geolocatie.

Sta de huidige origin toe:

Permissions-Policy: geolocation=(self), camera=(), microphone=()

Of sta een expliciete origin toe:

Permissions-Policy: geolocation=(self "https://maps.example")

Kopieer geen enorme lijst met elk bekend directief. Afzonderlijke directieven hebben verschillende browserondersteuning en sommige blijven experimenteel. Identificeer de mogelijkheden die de applicatie gebruikt en schakel vervolgens relevante ongebruikte mogelijkheden expliciet uit.

7. COOP, COEP en CORP: cross-origin-isolatie is geen universele standaard

Deze headers zijn verwant, maar lossen verschillende problemen op.

Cross-Origin-Opener-Policy

Cross-Origin-Opener-Policy: same-origin

COOP bepaalt of documenten die via navigatie of window.open() worden geopend een browsing-contextgroep delen. same-origin scheidt het document van cross-origin-openers en beperkt sommige XS-Leaks.

Het kan OAuth-popups, betaalvensters en integraties die op window.opener vertrouwen breken. In sommige gevallen is dit passender:

Cross-Origin-Opener-Policy: same-origin-allow-popups

Cross-Origin-Embedder-Policy

Cross-Origin-Embedder-Policy: require-corp

COEP vereist dat cross-origin no-cors-resources toestemming verlenen via CORP of met CORS worden opgehaald. Ontbrekende headers kunnen afbeeldingen, lettertypen, scripts, frames en andere assets van derden blokkeren.

Een alternatief is:

Cross-Origin-Embedder-Policy: credentialless

Dit staat sommige no-cors-resources toe zonder expliciete CORP, waarbij credentials zoals cookies worden verwijderd.

Cross-Origin-Resource-Policy

Cross-Origin-Resource-Policy: same-origin

CORP is een beleid op de resource zelf en kan gebruiken:

• same-origin,
• same-site,
• cross-origin.

Het is geen vervanging voor CORS. MDN documenteert ook een Chrome-probleem met gedeeltelijke PDF-weergave bij sommige CORP-implementaties, dus de header mag niet globaal worden toegepast zonder tests.

Het paar:

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

maakt cross-origin-isolatie mogelijk die vereist is door geselecteerde geavanceerde API's, waaronder volledige SharedArrayBuffer-toegang. Zet het niet in louter voor een scannerscore.

8. Veilige cookies en caching

Set-Cookie en Cache-Control worden niet altijd als securityheaders vermeld, maar ze beschermen sessies en gevoelige gegevens rechtstreeks.

Sessiecookie

Set-Cookie: __Host-session=RANDOM_VALUE; Path=/; Secure; HttpOnly; SameSite=Lax

• Secure beperkt de verzending tot HTTPS.
• HttpOnly voorkomt toegang via JavaScript.
• SameSite beperkt cross-site verzenden.
• __Host- vereist Secure, Path=/ en geen Domain, waardoor de cookie strakker aan de host wordt gebonden.

SameSite=Strict is sterker maar kan het terugkeren van login- of betalingsproviders verstoren. SameSite=None vereist Secure en zou alleen mogen worden gebruikt voor een werkelijk cross-site cookie.

Gevoelige responses

Cache-Control: no-store

Dit vraagt privé- en gedeelde caches om de response niet op te slaan. Gepersonaliseerde inhoud die wel in de browser maar niet door tussenpartijen mag worden gecachet, kan gebruiken:

Cache-Control: private, no-cache

MDN raadt aan gepersonaliseerde responses expliciet als private te markeren om onbedoelde gedeelde caching te voorkomen.

9. Beperk het prijsgeven van technologie

Headers zoals:

Server: nginx/1.24.0
X-Powered-By: PHP/8.4
X-AspNet-Version: 4.0.30319

maken fingerprinting eenvoudiger. Het verwijderen ervan verbergt de stack niet voor een vastberaden aanvaller, maar voorkomt het rechtstreeks prijsgeven van versies.

• verwijder X-Powered-By;
• schakel headers met frameworkversies uit;
• beperk de details in Server;
• publiceer geen bewust valse versie;
• verwar obscuriteit niet met patchen.

OWASP raadt aan X-Powered-By te verwijderen en Server te beperken, maar merkt op dat technologieën nog steeds op andere manieren kunnen worden afgeleid.

10. Verouderde headers en misleidend advies

X-XSS-Protection

Niet inschakelen:

X-XSS-Protection: 1; mode=block

OWASP waarschuwt dat verouderde XSS-filters kwetsbaarheden kunnen creëren in overigens veilige pagina's. Laat de header weg of schakel hem expliciet uit:

X-XSS-Protection: 0

Gebruik in plaats daarvan CSP, uitvoercodering en veilige API's.

Expect-CT

Expect-CT is in de praktijk verouderd omdat huidige clients Certificate Transparency vereisen voor moderne certificaten. MDN omschrijft het als grotendeels verouderd sinds juni 2021.

Public-Key-Pins

HPKP zou niet moeten worden ingezet. Een verkeerde pin kan gebruikers langdurig buitensluiten en de header is uit moderne browsers verwijderd. Geef de voorkeur aan correcte TLS, geautomatiseerde vernieuwing, CAA, certificaatmonitoring en zorgvuldig beoordeelde HSTS-preload.

Report-To

De oude:

Report-To: { ... }

is afgeschaft. Gebruik:

Reporting-Endpoints: csp="https://example.com/reports/csp"

Access-Control-Allow-Origin: *

CORS is geen bundel hardeningheaders om globaal toe te voegen. Access-Control-Allow-Origin versoepelt de Same-Origin Policy. API-responses met credentials kunnen wildcard * niet veilig combineren met geauthenticeerde cross-origin-toegang. Sta alleen vereiste origins toe en valideer ze aan de serverzijde.

11. Voorbeelden van serverconfiguratie

Nginx

add_header Content-Security-Policy "default-src 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none'; form-action 'self'; img-src 'self' data: https:; style-src 'self'; script-src 'self'; connect-src 'self'; upgrade-insecure-requests" always;
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;
add_header X-Content-Type-Options "nosniff" always;
add_header Referrer-Policy "strict-origin-when-cross-origin" always;
add_header Permissions-Policy "camera=(), microphone=(), geolocation=()" always;
add_header X-Frame-Options "DENY" always;

always is van belang omdat het de headers behoudt bij fout- en niet-standaard statusresponses.

Apache

<IfModule mod_headers.c>
  Header always set Content-Security-Policy "default-src 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none'; form-action 'self'; img-src 'self' data: https:; style-src 'self'; script-src 'self'; connect-src 'self'; upgrade-insecure-requests"
  Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"
  Header always set X-Content-Type-Options "nosniff"
  Header always set Referrer-Policy "strict-origin-when-cross-origin"
  Header always set Permissions-Policy "camera=(), microphone=(), geolocation=()"
  Header always set X-Frame-Options "DENY"
</IfModule>

PHP

<?php

header("Content-Security-Policy: default-src 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none'; form-action 'self'; img-src 'self' data: https:; style-src 'self'; script-src 'self'; connect-src 'self'; upgrade-insecure-requests");
header("Strict-Transport-Security: max-age=31536000; includeSubDomains");
header("X-Content-Type-Options: nosniff");
header("Referrer-Policy: strict-origin-when-cross-origin");
header("Permissions-Policy: camera=(), microphone=(), geolocation=()");
header("X-Frame-Options: DENY");

Headers moeten vóór de responsebody worden verzonden. Genereer voor elke request afzonderlijk een cryptografisch willekeurige nonce.

Node.js / Express

app.use((req, res, next) => {
  res.setHeader(
    "Content-Security-Policy",
    "default-src 'self'; base-uri 'self'; object-src 'none'; frame-ancestors 'none'; form-action 'self'; img-src 'self' data: https:; style-src 'self'; script-src 'self'; connect-src 'self'; upgrade-insecure-requests"
  );
  res.setHeader(
    "Strict-Transport-Security",
    "max-age=31536000; includeSubDomains"
  );
  res.setHeader("X-Content-Type-Options", "nosniff");
  res.setHeader("Referrer-Policy", "strict-origin-when-cross-origin");
  res.setHeader(
    "Permissions-Policy",
    "camera=(), microphone=(), geolocation=()"
  );
  res.setHeader("X-Frame-Options", "DENY");
  res.removeHeader("X-Powered-By");
  next();
});

Een site die CDN's, WebSockets, OAuth, betalingen of kaarten gebruikt, heeft een bredere maar nog steeds expliciete CSP nodig.

12. Een uitrolproces dat storingen voorkomt

Inventarisatie

Maak een lijst van alle origins voor scripts, styles, lettertypen en afbeeldingen; API- en WebSocket-endpoints; iframes; OAuth-/betaalpopups; CDN-resources; uploads van gebruikers; HSTS-subdomeinen en browsermogelijkheden die door de applicatie worden gebruikt.

Observeer

• voer CSP uit in Report-Only;
• verzamel rapporten en schendingen in de browserconsole;
• test elk kritiek gebruikerspad;
• neem mobiele en ondersteunde browsers mee;
• inspecteer foutpagina's, redirects en statische assets.

Dwing geleidelijk af

• begin met object-src, base-uri, frame-ancestors en form-action;
• ga over naar statische resources;
• dwing een strikte script-src als laatste af;
• verhoog de HSTS-max-age geleidelijk;
• test COOP/COEP afzonderlijk tegen popup- en cross-origin-integraties.

Bewaak regressies

CI-tests moeten representatieve URL's ophalen, dubbele of conflicterende headers detecteren, MIME-typen bevestigen, onbedoelde verwijdering van CSP/HSTS detecteren en end-to-end login- en betaalflows uitvoeren.

13. Hoe headers te testen

Controleer de response rechtstreeks:

curl -I https://example.com/

Volg redirects:

curl -IL https://example.com/

Inspecteer een specifieke resource:

curl -I https://example.com/assets/app.js

Verifieer de headers op de homepage, login, 404- en 500-responses; bevestig dat CSP niet met conflicterende beleidsregels wordt gedupliceerd; zorg dat HSTS alleen via HTTPS wordt verzonden; controleer MIME-typen; en verifieer dat een CDN of reverse proxy de headers niet heeft verwijderd.

De gratis POLPROG Security Headers Inspector controleert HSTS, CSP, framingbescherming en andere maatregelen. Gebruik de DNS & SSL Inspector voor certificaat- en DNS-controles, en Website Health Check voor een bredere beoordeling van SEO, prestaties, toegankelijkheid en beveiliging.

Implementatiechecklist

CSP

• Restrictieve default-src.
• object-src 'none'.
• Beperkte base-uri.
• frame-ancestors komt overeen met het werkelijke insluitmodel.
• form-action beperkt de formulierbestemmingen.
• Inline code gebruikt indien nodig een nonce of hash.
• De nonce is uniek per response.
• Geen ongerechtvaardigde 'unsafe-inline'.
• Geen ongerechtvaardigde 'unsafe-eval'.
• Beleid eerst getest in Report-Only.
• Rapportage-endpoint heeft rate limits en beperkte bewaartermijn.

HTTPS en HSTS

• Elke pagina en resource werkt via HTTPS.
• HTTP redirect rechtstreeks naar HTTPS.
• Certificaten worden bewaakt.
• Alle subdomeinen zijn geïnventariseerd.
• max-age in fasen verhoogd.
• includeSubDomains is veilig.
• preload pas toegevoegd na beoordeling van de gevolgen.

Overige maatregelen

• X-Content-Type-Options: nosniff.
• Correct Content-Type op elke response.
• Expliciete Referrer-Policy.
• Permissions-Policy schakelt ongebruikte mogelijkheden uit.
• Geen ALLOW-FROM in X-Frame-Options.
• COOP breekt OAuth of betalingen niet.
• COEP blokkeert geen vereiste assets van derden.
• CORP komt overeen met het deelmodel van elke resource.
• Sessiecookies gebruiken Secure, HttpOnly en een passende SameSite.
• Gevoelige responses gebruiken correcte Cache-Control.
• Headers met technologieversies zijn verwijderd.
• X-XSS-Protection is afwezig of uitgeschakeld.
• Expect-CT, HPKP en de oude Report-To zijn verwijderd.

Oordeel

Voor de meeste zakelijke websites en webapplicaties is de juiste volgorde:

1. Correcte HTTPS, MIME-typen en veilige cookies.
2. Een applicatiespecifieke CSP die via Report-Only wordt uitgerold.
3. HSTS in fasen ingezet.
4. nosniff, Referrer-Policy, Permissions-Policy en framingbescherming.
5. COOP, COEP en CORP alleen wanneer het cross-origin-model wordt begrepen.
6. Verwijdering van verouderde en informatielekkende headers.

De beste set securityheaders is niet de langste. Het is het kleinste beleid dat nauwkeurig bij de applicatie past, kritieke-padtesten doorstaat en na elke implementatie bewaakt blijft.