served/security-headers

Af content-framework-redaktionen · Opdateret
Servering · scope: served · severity: error

The full security header suite is present. Reglen served/security-headers kører i served-scope med severity 'error' og indgår i servering-domænet sammen med 4 andre kontrakter i frameworket.

Hvorfor security-headers findes

Static sites cannot set headers in HTML — the host config must send CSP, HSTS, X-Content-Type-Options, Referrer-Policy and Permissions-Policy on every HTML response. This is the Mozilla Observatory A+ baseline. Generate the host config with `pseo headers <host>` so it cannot drift.

Sådan håndhæves security-headers

Reglen security-headers evalueres mod den kørende server, fordi kravet bor i response headers eller statuskoder, som den statiske HTML ikke kan bære. Fejler en side, får agenten en finding, hvor fix-instruktionen for security-headers er formuleret som en konkret arbejdsordre med filnavne og målbare krav — aldrig et vagt råd. Severity 'error' betyder at et brud på security-headers fejler hele verifikationen med exit-kode 1, så hverken CI eller en agent kan skibe sitet før fundet er rettet.

Domænet: servering

Served-domænet verificerer det, HTML'en ikke kan bære: security headers, CSP-kvalitet, HSTS, komprimering og ægte 404-statuskoder. Reglerne kører mod den levende server og parres med adapters-pakken, der genererer host-konfigurationen fra én kanonisk kilde. Netop derfor hører security-headers hjemme her: kravet kan afgøres maskinelt, og dermed kan det håndhæves i stedet for blot at blive anbefalet.

Test og fixtures

Som alle kontrakter i frameworket har served/security-headers en mutant-test, der beviser at reglen fejler, når kravet brydes — en regel uden en fejlende test er ikke en regel. Golden-fixturet beviser omvendt, at en fuldt compliant side består security-headers sammen med de øvrige 85 regler, og denne demoside er selv underlagt hele kontrakten.

Relaterede regler

Tilbage til oversigten over alle 86 regler.