Säkerhetsheaders för webben: vad ni ska sätta, och varför

Säkerhetsheaders är instruktioner som er server skickar med varje svar och som talar om för webbläsaren hur sidan ska hanteras. De kostar nästan ingenting att lägga till, och de begränsar skadan av problem som ni ännu inte har hittat: ett injicerat skript, en sida som ramas in av en annan webbplats, en cookie som skickas över fel anslutning.

Den här guiden går igenom de headers som är värda att sätta på alla webbplatser, ett rimligt värde att börja med och vad en kontroll utifrån kan och inte kan se. Testa varje ändring i en testmiljö först. En strikt header som sätts slarvigt kan få en sida att sluta fungera lika säkert som en attack.

Exemplen använder example.com. Byt ut den mot er egen domän.

Var headers sätts

Headers kan sättas i applikationen, i webbservern, i en lastbalanserare eller i ett CDN. Välj ett lager och sätt dem där, så att de inte dubbleras eller skrivs över. Kontrollera vad en sida faktiskt returnerar:

curl -sI https://example.com/

Headers gäller per svar. En header på startsidan täcker inte en inloggningssida från en annan applikation, ett API på en subdomän eller en fil som levereras från en lagringstjänst. Kontrollera de sidor som spelar roll, inte bara startsidan.

Content-Security-Policy

Content Security Policy (CSP Level 3) anger vilka källor för skript, stilmallar, bilder, ramar och anslutningar som är legitima för sidan. Den stora nyttan är skyddet mot cross-site scripting (XSS): även om en angripare lyckas injicera ett skript, hindrar en strikt policy webbläsaren från att köra det.

En policy måste passa webbplatsen, så inför den först i rapportläge. Webbläsaren rapporterar vad som skulle ha blockerats, utan att blockera något:

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

Samla rapporter i en eller två veckor, lägg till de källor som webbplatsen faktiskt använder och byt sedan till den skarpa headern Content-Security-Policy. Undvik 'unsafe-inline' och 'unsafe-eval' i script-src: de tillåter precis det som policyn ska stoppa. Använd nonces eller hashar för inbäddade skript som ni inte kan ta bort.

Strict-Transport-Security

HSTS (RFC 6797) talar om för webbläsaren att bara nå er webbplats över HTTPS framöver, så att det första anropet när någon skriver example.com inte går okrypterat, där det kan avlyssnas:

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

Skicka headern i svar över HTTPS; över vanlig HTTP ignorerar webbläsarna den. Börja med ett kort max-age och lägg bara till includeSubDomains när alla subdomäner har HTTPS, eftersom webbläsarna kommer ihåg headern. Checklistan för TLS-certifikat tar upp HSTS preload och resten av HTTPS-uppsättningen.

X-Content-Type-Options

X-Content-Type-Options: nosniff

Headern hindrar webbläsaren från att gissa en fils typ utifrån innehållet och till exempel köra en uppladdad textfil som skript. Den har ett enda rimligt värde. Sätt den på alla svar och se till att servern skickar korrekta Content-Type-headers, eftersom nosniff får webbläsaren att lita på dem.

frame-ancestors och X-Frame-Options

Vid clickjacking laddas er sida osynligt i en ram på en annan webbplats, och användaren luras att klicka på den. Bestäm vilka webbplatser, om några, som får rama in era sidor.

Den moderna kontrollen är CSP-direktivet frame-ancestors. Den äldre headern X-Frame-Options (RFC 7034) gör samma sak i äldre webbläsare. Webbläsare som stöder båda använder frame-ancestors. Det skadar inte att sätta båda:

Content-Security-Policy: frame-ancestors 'self'
X-Frame-Options: SAMEORIGIN

Använd frame-ancestors 'none' och X-Frame-Options: DENY om era sidor aldrig ska kunna ramas in.

Referrer-Policy

När en användare följer en länk kan webbläsaren berätta för mottagaren vilken sida användaren kom från. Fullständiga adresser kan innehålla sökord, återställningskoder eller interna sökvägar. Referrer Policy begränsar vad som skickas:

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

Då skickas hela adressen inom er egen webbplats, bara ursprunget, till exempel https://example.com, till andra webbplatser, och ingenting alls vid byte från HTTPS till HTTP. Dagens webbläsare använder det här värdet som standard när headern saknas, men genom att sätta den blir valet uttryckligt. Använd no-referrer på sidor med känsliga adresser.

Permissions-Policy

Permissions Policy stänger av webbläsarfunktioner som er webbplats inte använder, så att inte heller ett kapat skript från tredje part kan använda dem:

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

Lista bara de funktioner ni vill neka, och låt det som webbplatsen verkligen behöver vara påslaget.

X-XSS-Protection

Headern styrde ett XSS-filter i äldre webbläsare. Dagens webbläsare har tagit bort filtret, och filtret kunde dessutom missbrukas för att läcka information från sidor. Nuvarande rekommendation, bland annat i OWASP HTTP Headers Cheat Sheet, är att uttryckligen stänga av det och lita till CSP:

X-XSS-Protection: 0

Cookieflaggor

Cookies bär sessioner, så deras attribut spelar lika stor roll som någon header (RFC 6265):

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

• Secure skickar bara cookien över HTTPS, så att den aldrig färdas okrypterad.
• HttpOnly döljer cookien för JavaScript, så att ett injicerat skript inte kan läsa sessionen och föra den vidare.
• SameSite=Lax (eller Strict för känsliga flöden) hindrar att cookien skickas med de flesta anrop som startas från andra webbplatser, vilket begränsar cross-site request forgery.

Sätt alla tre på cookies för sessioner och inloggning. En cookie som JavaScript verkligen behöver läsa ska inte innehålla något som ger åtkomst.

Det här bedömer TrustSek i dag

Modulen TLS och webbhygien gör ett anrop till https:// och ett till http:// på den domän ni anger, som en webbläsare skulle göra, och läser headrarna i svaren. Det är en avläsning av startsidan på just den värden.

Alla headers i guiden ger inte fynd. Kontrollen registrerar flera av dem, men bara de här bedöms i dag:

Fynden står på engelska, så som TrustSek rapporterar dem i dag.

En kommentar om X-XSS-Protection: fyndets egen text i appen beskriver headern som ett extra skydd för äldre webbläsare. Vi rekommenderar X-XSS-Protection: 0, som ovan, vilket också gör att fyndet försvinner.

Att det inte blir något fynd är inte samma sak som en välkonfigurerad webbplats. Kontrollen ser ett svar per protokoll, bedömer inte om en CSP är strikt eller tillåtande och kan inte se headers på sidor, subdomäner eller API:er som den inte anropade. Använd den som en första avläsning och kontrollera själva headrarna på de sidor som hanterar inloggning och personuppgifter. Metoden förklarar hur allvarlighetsgraden påverkar poängen.

Kontrollera er domäns headers, TLS och resten

Se vilka säkerhetsheaders och cookieflaggor er startsida skickar i dag, tillsammans med TLS, e-postsäkerhet och resten av bedömningen utifrån.

Er domän

Kontrollera er domän

Gratis, inget konto behövs. Tar ungefär 30 sekunder.