HSTS och preload: så tvingar du HTTPS utan att låsa in dig

HSTS-headern, HTTP Strict Transport Security, hör hemma på i princip varje sajt. Den tvingar webbläsaren att alltid välja HTTPS för din domän, även den gången någon råkar klicka på en gammal HTTP-länk. Direktivet preload, den lilla utökningen många guider rekommenderar i samma andetag, förtjänar en helt annan behandling. För nästan alla svenska sajtägare är preload fel val, och i oktober 2026 blir det fel på ett nytt sätt. Enligt Googles egen säkerhetsblogg ger Chrome då bort preloadens främsta fördel gratis, medan inlåsningen står kvar precis som förut.

Svenska guider om HTTPS brukar vara både pedagogiska och korrekta ända fram till just den punkten. De förklarar HSTS ordentligt, visar hur headern sätts, och landar sedan i rådet att man lika gärna kan kryssa i "preload" också, eftersom det känns som en starkare variant av samma sak. Problemet är att den som faktiskt förvaltar preload-listan säger raka motsatsen.

Den som förvaltar listan avråder från listan

Bakom Chromes inbyggda preload-lista står projektet hstspreload.org, som drivs i samarbete med Chrome-teamet och vars lista även Firefox, Safari och Edge bygger sina egna listor på. Deras egen rekommendation är ovanligt tydlig för att komma från upphovsmakarna själva.

"The benefits provided by HSTS preloading are minimal compared to the benefits provided by HSTS. While HSTS is recommended, HSTS preloading is not recommended."

De går längre än så. Till alla som skriver guider eller bygger verktyg som föreslår HSTS-inställningar (precis den kategori den här artikeln själv tillhör) skriver de rakt av att preload inte ska vara förvalt.

"If you maintain a project that provides HTTPS configuration advice or provides an option to enable HSTS, do not include the preload directive by default."

Det är alltså inte en obskyr invändning från en kritiker på sidlinjen. Det är standardrådet från dem som byggt och underhåller listan Chrome faktiskt läser.

Preload finns inte i standarden, det är en tillagd spärr

Det är lätt att anta att preload är ett protokolldirektiv bland andra, definierat i samma RFC som resten av HSTS. Så är det inte. RFC 6797, standarden från 2012 som definierar HSTS, är rakt på sak om vilka direktiv som faktiskt existerar i specifikationen.

"The two directives defined in this specification are described below."

De två direktiven är max-age, som säger hur länge webbläsaren ska komma ihåg att tvinga HTTPS för domänen, och includeSubDomains, som utökar den regeln till alla subdomäner. preload nämns inte som ett protokolldirektiv i RFC:n. Det är en konvention som Chrome introducerade utanför standarden, ett sätt att signalera "lägg in mig i den hårdkodade listan", som andra webbläsare sedan valde att följa. MDN:s referens för headern beskriver preload just så, som ett tillägg utanför RFC:n som endast har betydelse tillsammans med en anmälan till preload-listan. Skillnaden spelar roll för hur man ska tänka kring den. max-age och includeSubDomains är webbläsarbeteende du styr genom din egen header, i realtid. preload är en ansökan till en extern, hårdkodad lista som varken du eller webbläsaren kan ångra på egen hand.

Chrome 154 tar bort preloadens sista argument

Preloadens hela existensberättigande är att lösa "första besöket"-problemet. Webbläsaren kan inte känna till din HSTS-policy förrän den redan besökt din sajt en gång, vilket i teorin lämnar det första besöket oskyddat mot en angripare som sitter mellan användaren och nätet. Preload-listan löser det genom att bygga in kunskapen om din domän direkt i webbläsaren, före första besöket.

Enligt Googles säkerhetsblogg, publicerad i oktober 2025, planerar Chrome att med version 154 ta bort en stor del av anledningen att lösa just det problemet via preload. Chrome ska då, enligt samma inlägg, införa en ny och bredare standardinställning som är tänkt att göra i stort sett samma jobb, fast för hela webben på en gång.

"One year from now, with the release of Chrome 154 in October 2026, we will change the default settings of Chrome to enable "Always Use Secure Connections"."

Själva ordet "will change" markerar en avsikt satt i dag för ett datum drygt ett år fram i tiden, inte ett redan genomfört skifte. Chrome 154 är ännu inte här när det här skrivs, och Google har historiskt skjutit på liknande utrullningar förut. Riktningen är ändå tydlig, och den påverkar hur du bör väga preload-listans striktare variant av samma idé. Med "Always Use Secure Connections" påslaget som standard försöker Chrome varje anslutning över HTTPS, oavsett domän, och faller bara tillbaka på HTTP om användaren aktivt godkänner det efter en varning. Den varningen är, i Googles egen formulering, "bypassable". Det är just den skillnaden, klickbar varning kontra ingen väg alls förbi, som gör preload till ett tyngre åtagande än en vanlig HSTS-header, trots att båda i praktiken sätts med samma kryssruta.

De två första raderna kräver ingen ytterligare förklaring. Omfattningen gör det, och vi går igenom den lite längre ner.

Fällan i borttagningsformuläret

Det finns en väg ut ur preload-listan, men den är strängare konstruerad än den ser ut. Enligt hstspreload.org:s egen sida om borttagning räcker det i teorin att sluta skicka preload-direktivet i headern för att räknas som en begäran om borttagning. Men för att begäran faktiskt ska godkännas måste tre villkor vara uppfyllda samtidigt.

1. Domänen måste redan ligga i preload-listan, eller stå i kö för att läggas till.
2. Sajten måste serva HTTPS med ett giltigt certifikat.
3. Sajten måste skicka en giltig HSTS-header, utan preload-direktivet.

Läs villkor två igen. Nödutgången kräver en sajt som redan har fungerande HTTPS. Det låter som en självklarhet, men det är exakt den situation som brister när ett webbhotellsbyte går snett, ett certifikat inte hinner utfärdas på den nya servern, eller DNS pekar fel under en övergångsperiod. Har du redan flyttat och HTTPS inte fungerar kan du inte ens lämna in en giltig begäran om att bli borttagen. Du sitter fast i exakt det ögonblick du bäst hade behövt en väg ut.

Den poängen brukar saknas i råd som föreslår preload i förbifarten. Preload är inte en risk du åtgärdar i efterhand. Det är ett beslut du måste rulla tillbaka veckor, helst månader, innan du gör något som kan rubba HTTPS-driften, ett värdbyte, en certifikatomläggning, en flytt till ny infrastruktur. Även när allt går som det ska tar det, enligt samma sida, 6 till 12 veckor innan borttagningen når de flesta Chrome-användare, och längre för andra webbläsare.

Låsningen gäller alla subdomäner, även de du glömt fanns

Direktivet includeSubDomains är, som redan nämnt, en del av själva RFC:n och helt legitimt att använda utan preload. Kombinerat med preload blir konsekvensen bredare än många räknar med. hstspreload.org är explicita om det redan i sina rekommendationer för uppsättning.

"HSTS preloading applies to all subdomains, including internal subdomains that are not publicly accessible."

RFC 6797 ger i avsnitt 11.4 ett konkret exempel på var det gör ont i praktiken. En certifikatutfärdare kan behöva erbjuda sina CRL- och OCSP-tjänster (tjänster som låter andra system kontrollera om ett certifikat spärrats) över vanlig HTTP, ofta på en subdomän till en sajt som i övrigt är TLS-skyddad. Samma sak gäller interna verktyg, staging-miljöer eller ett gammalt intranät som råkar ligga under samma domän. Sätter du includeSubDomains tillsammans med preload tvingas alla dessa subdomäner köra HTTPS, oavsett om du någonsin tänkt på att de finns, och oavsett om de är redo för det.

max-age=0 stänger av HSTS. Preload rör det inte

Att skicka Strict-Transport-Security: max-age=0 är det som brukar kallas en knockout-header, ett sätt att omedelbart tala om för webbläsaren att glömma domänens HSTS-policy. För vanlig HSTS, satt via din egen header utan preload, fungerar det utmärkt.

Det gör ingenting för en domän som ligger i den hårdkodade preload-listan. Webbläsaren har redan domänen inbyggd, oberoende av vad din header säger just nu, och kommer fortsätta tvinga HTTPS tills den byggs om med en nyare lista, vilket i sin tur kräver att du gått igenom borttagningsprocessen ovan och väntat ut spridningstiden. max-age=0 är en nödbroms för HSTS. Den är verkningslös mot preload.

Ingen klickbar väg förbi

Anledningen till att preload känns så mycket hårdare än vanlig HSTS när något faktiskt går fel är inbyggd i hur webbläsare förväntas bete sig. RFC 6797, avsnitt 12.1, ger vägledning som webbläsarna sedan implementerat i praktiken.

"The user should not be presented with a dialog giving her the option to proceed."

Jämför det med Chrome 154:s planerade standardvarning, som Google själva beskriver som "bypassable", alltså möjlig att klicka sig förbi. Chrome rör sig mot mer skydd som standard, men behåller valfrihet för användaren i undantagsfall. Preload rör sig i motsatt riktning, mot mindre valfrihet, oavsett vad som faktiskt gick fel på servern.

Så trappar du upp HSTS utan att låsa in dig

hstspreload.org föreslår själva en stegvis upptrappning innan man ens funderar på preload, och den är enkel att följa.

1. 5 minuter, max-age=300; includeSubDomains. Testa i produktion utan att riskera mer än fem minuters låst HTTPS om något går fel.
2. 1 vecka, max-age=604800; includeSubDomains. Låt trafiken och eventuella subdomänproblem visa sig under en hel vecka.
3. 1 månad, max-age=2592000; includeSubDomains. Håll ögonen på trafik och eventuella felmeddelanden under hela perioden innan du går vidare.

Visar sig sajten stabil genom hela den trappan är nästa naturliga steg det som i praktiken brukar bli produktionens slutläge, ett helt års max-age, alltjämt utan preload. Det är, konkret, den konfiguration webguide.se själva kör. Vår server skickar Strict-Transport-Security: max-age=31536000; includeSubDomains, ett helt år, subdomäner inkluderade, utan preload-direktivet. Det går att verifiera själv på tio sekunder i vår egen SSL-kollare. Det är precis det läge hstspreload.org rekommenderar att man siktar mot, och stannar vid, om man inte har en mycket konkret anledning att gå längre.

Var det slås på utan att någon tänkt igenom det

I praktiken hamnar preload sällan i headern genom ett medvetet, informerat beslut. Det hamnar där för att det låg en kryssruta i vägen. WordPress-tillägget Really Simple Security, med enligt wordpress.org över tre miljoner aktiva installationer, har i sina HSTS-inställningar separata kryssrutor för "Include Preload" och "Include Subdomains". Ligger de intill varandra, framstår de lätt som två lika trygga tillval snarare än ett reversibelt direktiv och ett i praktiken irreversibelt. Samma mönster går igen i manuellt skriven .htaccess på cPanel- eller DirectAdmin-hotell, där en kopierad header-rad från ett forum eller en AI-chatt ofta redan innehåller preload som en förment "starkare" variant.

hstspreload.org beskriver konsekvensen rakt av, i en formulering som antyder att det här inte är ett teoretiskt scenario utan något de ser upprepat.

"We get regular emails from site operators who tried out HSTS this way, only to find themselves on the preload list without realizing that some subdomains cannot support HTTPS."

Vad vår egen SSL-kollare visar, och inte visar

Det är rimligt att fråga hur vårt eget webbverktyg hanterar just den här headern, så här är ett ärligt svar. Kollaren hämtar hela värdet av Strict-Transport-Security-headern från servern och skickar det vidare från backend. I gränssnittet i dag visas dock bara om headern finns eller inte, en grön bock eller ett rött kryss bredvid namnet, inte det faktiska innehållet. Du ser alltså om en sajt har satt på HSTS överhuvudtaget, men inte om den även skickar includeSubDomains eller, viktigare i det här sammanhanget, om den redan ligger på preload-listan. Det är en begränsning i hur resultatet presenteras i dag, värd att känna till om du använder verktyget för att bedöma en sajt du överväger att flytta till eller från.

Ska du ändå byta webbhotell, gör det här i god tid

Planerar du ett värdbyte och misstänker att din nuvarande sajt kan ligga i preload-listan, finns det ett protokoll värt att följa innan flytten, inte efter.

1. Kontrollera domänens aktuella status i Chrome via chrome://net-internals/#hsts, eller sök upp domänen direkt på hstspreload.org.
2. Ligger domänen i preload-listan, stryk preload ur headern och skicka in en begäran om borttagning medan din nuvarande HTTPS fortfarande fungerar felfritt.
3. Räkna med 6 till 12 veckor innan borttagningen slagit igenom hos de flesta Chrome-användare, längre för andra webbläsare, innan du planerar flytten.
4. Först därefter, flytta. Se till att det nya hotellets certifikat är fullständigt och korrekt kedjat redan från första anslutningen, annars riskerar du samma typ av tyst avbrott som beskrivs i vår genomgång av en ofullständig TLS-certifikatkedja.

Driver du egen server snarare än delad hosting hos flytten, är vår säkerhetschecklista för VPS ett rimligt nästa steg efter att HTTPS-grunden sitter. Och gäller bytet mer än bara HSTS-headern, DNS, e-post, innehåll, är vår fullständiga guide för att byta webbhotell värd att läsa innan du bokar flyttdatumet.