HTTP-sikkerhetsheadere er responsheadere som ber nettleseren bruke beskyttelser nettstedet ditt ellers måtte bygget selv: hold deg på HTTPS, kjør bare skript fra kilder du stoler på, ikke gjett filtyper, ikke la andre nettsteder vise siden i en ramme, og del mindre om hvor en besøkende kom fra. Seks headere dekker det meste: Strict-Transport-Security, Content-Security-Policy, X-Content-Type-Options, X-Frame-Options (eller CSP-ens frame-ancestors), Referrer-Policy og Permissions-Policy. De fleste krever én linje serverkonfigurasjon. Content-Security-Policy krever planlegging, så start den i Report-Only-modus.
De seks headerne i korte trekk
HeaderBeskytter motEn verdi å starte medStrict-Transport-SecurityTilkoblinger som nedgraderes til vanlig HTTPmax-age=31536000Content-Security-PolicyInjiserte skript (cross-site scripting)En policy som først er testet i Report-OnlyX-Content-Type-OptionsNettlesere som kjører en fil som en annen typenosniffX-Frame-Options eller frame-ancestorsClickjacking via rammerSAMEORIGIN og frame-ancestors ‘self’Referrer-PolicyFullstendige adresser som lekker til andre nettstederstrict-origin-when-cross-originPermissions-PolicyUbrukte nettleserfunksjoner som blir forespurtcamera=(), microphone=(), geolocation=()
Strict-Transport-Security (HSTS)
Selv med en omdirigering fra HTTP til HTTPS sender en besøkende som skriver inn domenet ditt, den første forespørselen over vanlig HTTP, der den kan leses eller endres underveis. HSTS ber nettleseren bruke HTTPS for domenet ditt fra da av, så lenge max-age angir, i sekunder:
Strict-Transport-Security: max-age=31536000
Start kort. Nettlesere følger HSTS til den utløper, så en feil blir sittende. Prøv max-age=300 i noen dager, og øk den deretter til et år (31536000).
includeSubDomains gjør at regelen gjelder alle underdomener. Legg den bare til når alle sammen, også gamle staging- og e-postservere, fungerer over HTTPS.
preload ber om å få domenet bygget inn i nettlesere via hstspreload.org, som krever en max-age på minst et år og includeSubDomains. Det tar lang tid å bli fjernet, så regn det som permanent.
Nettlesere ignorerer HSTS i svar over vanlig HTTP. Send den over HTTPS, og hold øye med sertifikatet: med HSTS kan man ikke klikke seg forbi et utløpt sertifikat.
Content-Security-Policy
En Content Security Policy angir hvor siden kan laste skript, stiler, bilder, fonter og rammer fra, og hvor skjemaer kan sende data til. Får en angriper et skript inn på siden, via et kommentarfelt eller en kompromittert plugin, nekter nettleseren å kjøre det med mindre policyen tillater kilden. Den er den mest effektive av de seks og den letteste å gjøre feil, siden en for streng policy ødelegger din egen analyse, chat-widget eller betalingsskjema.
Start med Report-Only
Send policyen som Content-Security-Policy-Report-Only først. Nettleseren håndhever ingenting, men rapporterer hvert brudd til adressen i report-uri (eller den nyere report-to) og logger det i konsollen. Et utgangspunkt for et nettsted som serverer sine egne filer:
Content-Security-Policy-Report-Only: default-src ‘self’; script-src ‘self’; style-src ‘self’; img-src ‘self’ data:; font-src ‘self’; object-src ‘none’; base-uri ‘self’; form-action ‘self’; frame-ancestors ‘self’; report-uri /csp-report
Bla gjennom nettstedet, samle rapportene i en uke eller to, og legg til kildene du faktisk bruker, for eksempel analyse- eller betalingsleverandøren din. Når rapportene bare viser ting du vil blokkere, sender du den samme policyen som Content-Security-Policy.
Inline-skript: nonces, ikke unsafe-inline
En streng policy blokkerer inline <script>-blokker og onclick-attributter, siden et injisert skript ser likt ut. Legger du til ‘unsafe-inline’, forsvinner problemet, og det meste av beskyttelsen med det. Gi i stedet hver respons en tilfeldig nonce, oppgi den i policyen som ‘nonce-…’, og sett samme verdi på dine egne script-tagger; flytt inline hendelseshåndterere til skriptfiler. Tag-managere som injiserer egne skript, krever ekstra omtanke, siden hver tagg de legger til også må tillates.
X-Content-Type-Options
Nettlesere pleide å gjette filtypen ut fra innholdet når serverens Content-Type så feil ut. Det gjorde at et opplastet «bilde» kunne kjøre som et skript. X-Content-Type-Options: nosniff slår av gjettingen. Den har én gyldig verdi og ingen kjente ulemper, så lenge serveren din sender riktige innholdstyper, så send den i alle svar.
X-Frame-Options og frame-ancestors
Ved et clickjacking-angrep viser et annet nettsted siden din i en usynlig ramme og lurer besøkende til å klikke på knapper i den. X-Frame-Options: DENY stopper all innramming, og SAMEORIGIN tillater bare dine egne sider. CSP-direktivet frame-ancestors gjør det samme med mer kontroll, for eksempel en liste over partnernettsteder, og har forrang i nettlesere som støtter det. Send begge: frame-ancestors for dagens nettlesere, X-Frame-Options for eldre. Den gamle verdien ALLOW-FROM støttes ikke lenger, så bruk frame-ancestors for alt utover ditt eget opphav.
Referrer-Policy
Når en besøkende følger en lenke, forteller nettleseren det neste nettstedet hvor de kom fra, i headeren Referer. Uten begrensninger kan det være hele adressen, inkludert et søk, et tilbakestillingstoken eller et ordrenummer i URL-en. strict-origin-when-cross-origin sender hele adressen innenfor ditt eget nettsted, bare domenet til andre nettsteder, og ingenting fra HTTPS til HTTP. Det er det dagens nettlesere gjør når headeren mangler, men å sende den gjør valget eksplisitt. Bruk no-referrer på sider med private data i URL-ene, og unngå unsafe-url, som sender alt overalt.
Permissions-Policy
Permissions-Policy, tidligere Feature-Policy, slår av nettleserfunksjoner nettstedet ditt ikke bruker, for siden og for hver ramme som er innebygd i den. En tom liste, (), betyr at ingen får bruke funksjonen:
Permissions-Policy: camera=(), microphone=(), geolocation=(), payment=(), usb=()
Utelat funksjonene du bruker, eller tillat dem for ditt eget opphav med (self), for eksempel payment=(self) i en nettbutikk med en betalingsknapp.
Headere du kan droppe
X-XSS-Protection styrte et filter som dagens nettlesere har fjernet. Utelat den, eller send 0.
Expect-CT og Public-Key-Pins er foreldet. Pinning kunne stenge besøkende ute fra et nettsted, og derfor droppet nettleserne det.
Server og X-Powered-By er ikke sikkerhetsheadere, men nøyaktige versjonsnumre i dem hjelper angripere med å velge et angrep. Kort dem ned der serveren din tillater det.
Hvor du setter dem
Sett headerne på ett sted, så nær kanten som mulig: webserveren, CDN-et eller applikasjonens middleware. I nginx og Apache:
# nginx (in the server block)
add_header Strict-Transport-Security «max-age=31536000» always;
add_header X-Content-Type-Options «nosniff» always;
add_header X-Frame-Options «SAMEORIGIN» always;
add_header Referrer-Policy «strict-origin-when-cross-origin» always;
add_header Permissions-Policy «camera=(), microphone=(), geolocation=()» always;
# Apache (.htaccess or virtual host, with mod_headers)
Header always set X-Content-Type-Options «nosniff»
Header always set Referrer-Policy «strict-origin-when-cross-origin»
To detaljer i nginx overrasker mange. Uten always legges headerne bare til i vellykkede svar, ikke på feilsider. Og en location-blokk med en egen add_header dropper alle fra server-blokken, så én enkelt cache-header for bilder kan i stillhet fjerne sikkerhetsheaderne dine der. Se også opp for at samme header settes to ganger, av serveren og av applikasjonen eller CDN-et: nettlesere håndterer duplikater ulikt fra header til header, så velg én eier for hver.
Slik sjekker du headerne dine
Fra en terminal skriver curl -sI https://example.com ut responsheaderne. Sjekk også den endelige adressen etter omdirigeringer, en feilside og en statisk fil, siden hver av dem kan serveres av en annen del av stacken din. I en nettleser viser Nettverk-fanen i utviklerverktøyene headerne for hver forespørsel, og konsollen viser CSP-brudd.
Eller bruk den gratis HTTP-headersjekken vår. Den lister opp hver header en URL sender etter å ha fulgt omdirigeringer, markerer hvilke av de seks sikkerhetsheaderne som mangler, flagger noen verdier som opphever dem, som en kort HSTS-max-age, en CSP som bare er Report-Only, eller unsafe-url, og viser hvordan siden caches og hvor tiden går. Den sjekker at headerne finnes; den vurderer ikke hva en Content Security Policy tillater, så det må du gå gjennom selv.
Sørg for at de ikke forsvinner
Sikkerhetsheadere går sjelden i stykker med et smell. De forsvinner når et nettsted flyttes til en ny server, et CDN byttes, en plugin oppdateres eller noen legger til en location-blokk, og nettstedet fortsetter å fungere, så ingen merker det. En HTTP-monitor i Uptimechecks oppetidsovervåking kan sjekke responsheadere ved hver forespørsel, opptil 10 responssjekker per monitor, for eksempel:
Strict-Transport-Security finnes.
X-Content-Type-Options er lik nosniff.
Content-Security-Policy inneholder frame-ancestors.
Hver sjekk må holde for at monitoren skal regnes som oppe, så en manglende header setter den til nede, en ny sjekk bekrefter det, og du får et varsel. Legg headersjekkene på en egen monitor hvis du ikke vil at de skal telle mot sidens oppetid. Sjekkene kjører så ofte som hvert minutt fra Stockholm, London og New York; se hvordan du overvåker et API-endepunkt for oppsett av responssjekker, og sjekklisten for vedlikehold av nettsteder for resten av rutinen.
Få vite det samme dag en header forsvinner. Prøv Uptimecheck gratis i 14 dager, uten kredittkort.