Vad är HSTS? HTTP Strict Transport Security förklarat

Din webbplats omdirigerar förmodligen redan till HTTPS, och hänglåset visas som det ska. Men varje gång en återkommande besökare skriver din adress utan https:// skickar webbläsaren ändå en okrypterad HTTP-förfrågan innan din omdirigering hinner svara. På fientliga nätverk – flygplats-Wi-Fi, hotellnät, en kapad router – är den enda förfrågan öppningen en angripare behöver. HTTP Strict Transport Security (HSTS) stänger den för gott: en enda svarsheader som säger åt webbläsaren att aldrig mer prata oskyddad HTTP med din domän.

Gapet är verkligt: enligt W3Techs (juli 2026) använder 90,1 % av alla webbplatser HTTPS som standard, men bara 34,1 % skickar en HSTS-header. Nio av tio krypterar; knappt en av tre upprätthåller det.

Vad är HSTS?

HSTS (HTTP Strict Transport Security) är en säkerhetspolicy som standardiserades i RFC 6797 redan 2012. Den består av en enda HTTP-svarsheader:

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

När webbläsaren tar emot headern över en giltig HTTPS-anslutning kommer den ihåg – i max-age sekunder – att din värd endast får nås via HTTPS. Från det ögonblicket gäller:

• Varje http://-länk, bokmärke eller inskriven adress till din domän skrivs om till https:// inuti webbläsaren (en intern 307-omdirigering), innan ett enda paket lämnar enheten.
• Certifikatvarningar på din webbplats blir omöjliga att klicka förbi: ingen "Fortsätt ändå"-länk. Är certifikatet trasigt – eller avlyssnar någon anslutningen – vägrar webbläsaren, punkt slut.

Alla stora webbläsare – Chrome, Edge, Firefox, Safari – har stött HSTS i ungefär ett decennium, på både dator och mobil.

Varför räcker inte en HTTPS-omdirigering?

En klassisk 301-omdirigering från HTTP till HTTPS sker på serversidan – webbläsaren måste först skicka den okrypterade HTTP-förfrågan, och en angripare mellan besökaren och servern ser den innan din omdirigering ens svarar. Det är precis så SSL-stripping fungerar, en nedgraderingsattack som demonstrerades av Moxie Marlinspike redan 2009: angriparen håller kvar offret på HTTP och pratar själv HTTPS med den riktiga servern – och läser allt däremellan.

Vad varje nivå av HTTPS-upprätthållande faktiskt skyddar.

Behåll omdirigeringen – den behövs för förstagångsbesökare och för preload-kraven – men var medveten om vad den inte klarar på egen hand.

Så fungerar HSTS, steg för steg

1. Första besöket. Webbläsaren laddar https://example.com, svaret innehåller Strict-Transport-Security-headern och policyn sparas.
2. Varje besök därefter. Alla försök att nå http://example.com uppgraderas internt till HTTPS. En paketavlyssning på nätverket skulle inte visa någon okrypterad förfrågan alls.
3. Timern förlängs löpande. Varje nytt HTTPS-svar med headern nollställer max-age, så återkommande besökare förblir skyddade.
4. Hårt stopp vid certifikatfel. Utgångna, självsignerade eller manipulerade certifikat ger en felsida som inte går att klicka sig förbi.

De tre direktiven

Så aktiverar du HSTS på din server

Lägg till headern endast i HTTPS-konfigurationen – webbläsare ignorerar HSTS som skickas över oskyddad HTTP, enligt specifikationen.

nginx (i server-blocket som lyssnar på 443):

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains" always;

Apache (med mod_headers aktiverat, i HTTPS-vhosten):

Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"

IIS (web.config):

<httpProtocol>
  <customHeaders>
    <add name="Strict-Transport-Security" value="max-age=31536000; includeSubDomains" />
  </customHeaders>
</httpProtocol>

Cloudflare: SSL/TLS → Edge Certificates → HTTP Strict Transport Security (HSTS) → Aktivera, och välj max-age och underdomäninställningar i panelen.

Bekräfta sedan att headern verkligen skickas: öppna din webbplats, titta under Nätverk-fliken i webbläsarens utvecklarverktyg och leta efter strict-transport-security bland svarsheadrarna – eller kör en gratis FortifyNet-skanning som flaggar en saknad eller svag HSTS-policy.

Rulla ut gradvis

En felaktig HSTS-policy låser ute besökare från trasiga HTTP-resurser under hela återstående max-age – du kan inte återkalla den på distans annat än genom att servera max-age=0 över giltig HTTPS till varje berörd webbläsare. Trappa upp i stället:

HSTS preload: stäng luckan vid första besöket

Vanlig HSTS bygger på trust on first use: en helt ny besökares allra första förfrågan är oskyddad tills den första headern anländer. Preload-listan löser det – din domän levereras inbyggd i webbläsaren som HTTPS-only, så inte ens besök nummer ett rör oskyddad HTTP.

Anmälan är gratis på hstspreload.org (listan underhålls av Chromium och används även av Edge, Firefox och Safari). Kraven:

• Ett giltigt TLS-certifikat.
• HTTP omdirigerar till HTTPS på samma värd (port 80 → 443).
• HSTS-headern skickas i HTTPS-svaret på huvuddomänen med max-age på minst 31536000 (1 år), plus både includeSubDomains och preload.
• Varje underdomän – inklusive www – nås över HTTPS.

Betrakta preload som en enkelriktad dörr. Borttagning ur listan tar månader att nå ut via webbläsarnas releasecykler. Förladda inte förrän varje underdomän – även interna som intranet. eller mail. – har fungerande HTTPS.

Läget 2026: HTTPS överallt, upprätthållandet släpar

HTTPS är närmast universellt, men bara ungefär en tredjedel av webbplatserna upprätthåller det med HSTS (källa: W3Techs, juli 2026).

Webbläsarna driver hårt åt samma håll. I Chrome 147 (april 2026) aktiverade Google "Always Use Secure Connections" för de över 1 miljard användare som har Enhanced Safe Browsing, och med Chrome 154 (oktober 2026) blir det standard för alla: Chrome provar HTTPS först och varnar innan publika HTTP-sidor laddas.

Gör det HSTS överflödigt? Nej. Chromes varning går att klicka förbi; HSTS är serverns egen icke-förbigångbara garanti. Den fungerar i alla webbläsare oavsett inställningar, täcker alla dina underdomäner och blockerar certifikatfel. De två kompletterar varandra.

Vanliga HSTS-misstag

• Att slå på includeSubDomains i blindo – en bortglömd HTTP-underdomän (intranät, staging, en skrivarportal) blir oåtkomlig under hela max-age.
• Att skicka headern över HTTP – ofarligt men verkningslöst; webbläsare ignorerar den.
• Ett max-age på några minuter i produktion – nästan noll skydd, och det underkänns för preload.
• Att glömma HSTS efter server- eller CDN-flytt – policyn löper tyst ut och ingen märker något.

Vanliga frågor

Ersätter HSTS min omdirigering från HTTP till HTTPS? Nej. Behåll omdirigeringen: förstagångsbesökare behöver den, och preload-listan kräver den.

Kan jag ångra HSTS? Servera Strict-Transport-Security: max-age=0 över HTTPS så släpper webbläsarna policyn vid nästa besök. Borttagning ur preload-listan går mycket långsammare – månader – därför trappar man upp försiktigt.

Påverkar HSTS SEO? Bara positivt: användare och sökmotorer hamnar garanterat på en kanonisk HTTPS-version av sajten. Det finns ingen nackdel för rankingen.

Hur vet jag om min sajt skickar HSTS? Kontrollera svarsheadrarna i webbläsarens utvecklarverktyg (Nätverk-fliken) och leta efter strict-transport-security – eller kör en gratis FortifyNet-skanning som kontrollerar HSTS tillsammans med övriga säkerhetsheaders.

Räcker HSTS som enda skydd? Det är en av flera headers en härdad webbplats skickar. Kombinera med Content-Security-Policy, X-Content-Type-Options med flera – se vår kompletta guide till säkerhetsheaders.

Testa din HSTS på 60 sekunder

Den kostnadsfria FortifyNet-skanningen testar din SSL/TLS-konfiguration, HSTS och alla andra säkerhetsheaders, DNS och e-postautentisering samt exponering på dark web – på ungefär en minut, utan registrering. Saknas HSTS eller är den felkonfigurerad ser du exakt vad som ska åtgärdas.

Relaterade guider

• HTTP Security Headers: Den kompletta guiden för 2026
• HTTP-säkerhetsheaders med exempel för nginx & Apache
• SSL-certifikat: A+ betyg i SSL Labs – komplett guide
• "Din anslutning är inte privat": vad felet betyder och hur du åtgärdar det