HTTP Säkerhetsheaders: Den kompletta guiden för 2026

Varför säkerhetsheaders spelar roll

HTTP-säkerhetsheaders är direktiv som skickas av din webbserver och som instruerar webbläsare om hur de ska bete sig när de visar din webbplats. Att lägga till dem kräver inga ändringar i din applikationskod - bara konfiguration av webbservern - och ändå är de ett av de mest effektiva försvaren mot ett brett spektrum av vanliga webbattacker, däribland Cross-Site Scripting (XSS), clickjacking och innehållsinjektion.

Många webbplatser försummar säkerhetsheaders helt och hållet. En genomsökning av de en miljon största webbplatserna visar gång på gång att de flesta saknar åtminstone några kritiska headers. Det är en förlorad möjlighet, eftersom dessa headers är gratis och enkla att lägga till.

HSTS - HTTP Strict Transport Security

HSTS är en header som säger till webbläsare: anslut aldrig till den här webbplatsen över vanlig HTTP, oavsett vad. När en webbläsare väl har sett en HSTS-header från din webbplats kommer den automatiskt att uppgradera alla framtida HTTP-förfrågningar till HTTPS - även om användaren skriver "http://" i adressfältet eller klickar på en HTTP-länk. Detta är en av de viktigaste säkerhetsheaders du kan lägga till.

Headern har tre viktiga parametrar. Värdet "max-age" talar om för webbläsaren hur länge (i sekunder) den ska komma ihåg den här policyn - du bör sätta detta till minst ett år (31536000 sekunder). Flaggan "includeSubDomains" utökar skyddet till alla dina underdomäner. Flaggan "preload" talar om för webbläsare att du vill bli inkluderad i HSTS preload-listan - en lista som är inbakad direkt i Chrome, Firefox och andra webbläsare så att även det allra första besöket på din webbplats är skyddat.

På nginx lägger du till den här headern med direktivet add_header inuti ditt server-block. På Apache använder du Header-direktivet inuti ett VirtualHost-block. Inkludera alltid nyckelordet "always" för att säkerställa att headern skickas även vid felsvar.

Innan du sätter en lång max-age, försäkra dig absolut om att hela din webbplats - inklusive alla underdomäner - fungerar korrekt över HTTPS. Att sätta HSTS med en lång max-age och sedan upptäcka att en underdomän inte stöder HTTPS kan låsa ute användare i månader.

CSP - Content Security Policy

Content Security Policy är den mest kraftfulla säkerhetsheadern som finns, och även den mest komplexa att konfigurera korrekt. Den talar om för webbläsare exakt vilka innehållskällor som tillåts laddas på din sida - skript, stilmallar, bilder, typsnitt och mer. Detta är ditt primära försvar mot Cross-Site Scripting (XSS)-attacker, där en angripare lyckas injicera skadlig JavaScript på din sida.

En CSP fungerar genom att vitlista betrodda källor. Du kan till exempel ange att skript endast får laddas från din egen domän och från Google Analytics, att stilmallar endast får komma från din egen domän, och att bilder får komma var som helst ifrån över HTTPS. Allt innehåll som inte matchar dessa regler blockeras av webbläsaren innan det kan köras.

Det mest effektiva sättet att implementera CSP är gradvis. Börja med att lägga till en "Content-Security-Policy-Report-Only"-header i stället för "Content-Security-Policy". Det innebär att policyn inte tvingas igenom - överträdelser rapporteras till dig men innehållet laddas ändå. På så sätt kan du samla in överträdelserapporter, identifiera alla legitima tredjepartsresurser som din webbplats faktiskt laddar, och bygga upp din policy utan att förstöra någonting. Efter en eller två veckors datainsamling växlar du till den tvingande versionen.

En vanlig fallgrop är "unsafe-inline" - ett direktiv som tillåter inline-skript och inline-stilar. Även om detta gör det enkelt att implementera CSP utan att förstöra din webbplats, minskar det dramatiskt det skydd den erbjuder, eftersom de flesta XSS-attacker bygger på att injicera inline-skript. Ett bättre tillvägagångssätt är att använda "nonces" eller "hashes" för att tillåta specifika inline-skript samtidigt som injicerade blockeras.

X-Frame-Options

Headern X-Frame-Options styr om din webbplats får bäddas in i en iframe på en annan domän. Detta skyddar mot clickjacking-attacker, där en angripare placerar din webbplats i en osynlig iframe ovanpå sin egen sida. Besökaren tror att hen klickar på något på angriparens sida men klickar i själva verket på din webbplats - och godkänner kanske en transaktion, klickar på en "acceptera"-knapp eller utför någon annan handling utan att inse det.

Det rekommenderade värdet är "SAMEORIGIN", som tillåter att din webbplats bäddas in i iframes endast från sidor på din egen domän. "DENY" förhindrar inbäddning helt och hållet. Det äldre alternativet "ALLOW-FROM" är föråldrat och stöds inte av moderna webbläsare.

Observera att om du har en modern CSP konfigurerad kan du använda CSP-direktivet "frame-ancestors" i stället för X-Frame-Options - det ger mer finkornig kontroll. För maximal kompatibilitet i alla webbläsare är det dock god praxis att inkludera båda.

X-Content-Type-Options

Den här enkla men viktiga headern har ett enda värde: "nosniff". Den hindrar webbläsare från "MIME-sniffing" - att gissa vilken typ av innehåll en fil innehåller baserat på dess faktiska innehåll snarare än den deklarerade Content-Type-headern.

MIME-sniffing låter ofarligt men kan utnyttjas. Om en angripare kan få dig att hosta en fil som ser ut som HTML eller JavaScript för en webbläsares innehållssniffare - även om du tror att det är en bild- eller textfil - kan webbläsaren köra den som ett skript. Att lägga till "nosniff" säger till webbläsare att alltid respektera den deklarerade innehållstypen och aldrig gissa.

Referrer-Policy

När en användare klickar på en länk från din webbplats till en annan sida inkluderar webbläsare automatiskt en "Referer"-header (notera felstavningen - den är historisk) som talar om för destinationssidan varifrån användaren kom. Detta kan oavsiktligt läcka känslig information om dina URL:er innehåller sessionstokens, sökfrågor eller andra privata data i query-strängen.

Headern Referrer-Policy styr vilken information som skickas. Det rekommenderade värdet "strict-origin-when-cross-origin" skickar hela URL:en för förfrågningar inom samma origin (användbart för din egen analys) men skickar endast domänen (inte hela URL:en) för förfrågningar mellan olika origins. Detta skyddar känsliga URL-parametrar samtidigt som användbar referrer-information bevaras för din egen webbplats.

Permissions-Policy

Permissions-Policy (tidigare kallad Feature-Policy) styr vilka webbläsarfunktioner och API:er din sida får använda. Detta inkluderar potentiellt känsliga funktioner som kameran, mikrofonen, geolokalisering, payment request API och mer. Genom att uttryckligen inaktivera funktioner du inte använder hindrar du tredjepartsskript (annonsnätverk, analysverktyg, inbäddat innehåll) från att komma åt dessa funktioner även om de försöker.

Vanliga frågor

Kommer en CSP att förstöra min webbplats? Det kan hända, till en början. CSP blockerar allt som inte uttryckligen tillåts. Om du har inline-skript, inline-stilar eller tredjepartsresurser som du inte har vitlistat kommer de att blockeras. Lösningen är att använda Report-Only-läge först och lägga tid på att samla in överträdelserapporter innan du växlar till tvingande läge.

Vad är Server-headern och bör jag dölja den? Server-headern avslöjar din webbservermjukvara och version - till exempel "nginx/1.24.0". Den informationen är användbar för angripare som vill rikta in sig på kända sårbarheter i specifika programvaruversioner. Du bör undertrycka eller generalisera den här headern. I nginx, sätt "server_tokens off". I Apache, använd "ServerTokens Prod".

Påverkar dessa headers webbplatsens prestanda? Försumbart. Headers lägger till några byte till varje HTTP-svar men har ingen märkbar inverkan på laddningstiden. Säkerhetsfördelarna uppväger vida varje marginell overhead.

Bör jag lägga till säkerhetsheaders på HTTP-svar såväl som HTTPS? Ja - konfigurera dem på båda, men kom ihåg att HSTS endast bör skickas över HTTPS. HSTS som skickas över HTTP ignoreras och kan orsaka förvirring.