Så konfigurerar du HSTS utan att låsa dig ute

HSTS är enkelt tills det inte är det

HTTP Strict Transport Security, vanligtvis förkortat HSTS, säger till webbläsare: ”för den här webbplatsen, använd alltid HTTPS.” När en webbläsare tar emot headern över en giltig HTTPS-anslutning kommer den ihåg regeln under den tid du anger.

Det är användbart. Det förhindrar protokollnedgraderingsattacker, minskar oavsiktliga osäkra förfrågningar och undviker det besvärliga ögonblicket när en användare skriver example.com och kortvarigt går via vanlig HTTP innan den omdirigeras.

Det är också klibbigt. Om du publicerar fel HSTS-policy kan webbläsare fortsätta att tillämpa den långt efter att du har tagit bort headern från din server. Det är så team låser sig ute: inte exakt från sin egen adminpanel, utan från användares webbläsare, subdomäner, staging-system, äldre endpoints och bortglömda tjänster som inte är redo för tvingad HTTPS.

Målet är inte att undvika HSTS. Målet är att driftsätta det som en migrering, inte som en strömbrytare.

Vad HSTS-headern faktiskt gör

En typisk HSTS-header ser ut så här:

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

Den har tre viktiga delar:

• max-age: hur länge, i sekunder, webbläsaren ska tvinga HTTPS för den här värden.
• includeSubDomains: om regeln också gäller för varje subdomän.
• preload: en signal om att du vill att domänen ska ingå i webbläsarnas preload-listor.

Webbläsaren litar bara på den här headern när den tar emot den över giltig HTTPS. Om certifikatet är ogiltigt, utgånget eller inte matchar ska webbläsaren inte acceptera en ny HSTS-policy från det svaret.

När policyn har lagrats uppgraderas framtida försök att besöka http://example.com av webbläsaren till https://example.com innan förfrågan skickas. Det är integritetsvinsten: den osäkra förfrågan lämnar aldrig enheten.

Lockout-scenarier att undvika

De flesta HSTS-misslyckanden orsakas inte av huvudwebbplatsen. De händer i kanterna.

1. En bortglömd subdomän är inte redo för HTTPS

includeSubDomains låter prydligt, men det är absolut. Om du sätter det på example.com gäller det för:

• www.example.com
• api.example.com
• old-crm.example.com
• printer-setup.example.com
• staging.example.com
• allt annat under den domänen

Om någon av dessa värdar inte kan leverera giltig HTTPS kommer användare med HSTS-policyn cachad inte att kunna nå dem via HTTP.

2. Ett certifikat går ut

Utan HSTS klickar användare ibland sig vidare förbi certifikatvarningar. Det är inte god säkerhetspraxis, men det händer.

Med HSTS tillåter moderna webbläsare inte enkel förbikoppling av certifikatfel för den värden. Det är själva poängen. Det betyder också att certifikatförnyelse behöver vara tråkig, övervakad och testad.

3. Staging eller interna verktyg ligger under produktionsdomänen

Att lägga interna verktyg under *.example.com kan bli smärtsamt när föräldradomänen använder includeSubDomains. Om dessa verktyg använder självsignerade certifikat, privata certifikatutfärdare, gamla TLS-konfigurationer eller ingen HTTPS alls kommer HSTS att synliggöra genvägen.

Det är en anledning till att många team håller interna och experimentella system under en separat domän som har sin egen säkerhetspolicy.

4. Preload behandlas som en rutinmässig kryssruta

HSTS preload är inte bara ännu ett direktiv. Det betyder att din domän kan levereras inuti webbläsare som enbart HTTPS innan någon användare har besökt din webbplats.

Det stänger luckan vid ”första besöket”, men är mycket svårare att ångra. Borttagning från preload-listor kan ta veckor eller månader att nå användare, beroende på webbläsarnas releasecykler. Preload passar stabila, mogna domäner. Det passar inte en webbplats som fortfarande upptäcker sin subdomäninventering.

En säker utrullningsplan

Steg 1: Granska varje värdnamn du kontrollerar

Innan du sätter includeSubDomains, lista varje värdnamn under domänen. DNS-poster är en början, men inte hela bilden. Kontrollera CDN-konfigurationer, hostingpaneler, e-postrelaterade värdnamn, gamla marknadsföringsverktyg, lagringsbucketar och intern dokumentation.

För varje värdnamn, svara på:

• Levererar det HTTP, HTTPS eller båda?
• Är HTTPS-certifikatet giltigt och förnyas det automatiskt?
• Omdirigerar det HTTP till HTTPS rent?
• Är det tänkt att vara publikt?
• Behövs det fortfarande?

Om ditt team redan har vanor för header-felsökning i produktion passar detta naturligt bredvid kontroller av omdirigeringar och headers. Vi gick igenom det arbetsflödet i en liten verktygslåda för att felsöka omdirigeringar och HTTP-headers i produktion.

Steg 2: Åtgärda HTTPS innan du lägger till HSTS

HSTS gör inte en trasig HTTPS-konfiguration säker. Det gör bara HTTPS obligatoriskt.

Innan du aktiverar det, verifiera:

• TLS-certifikat täcker rätt värdnamn.
• Certifikat förnyas automatiskt.
• HTTP omdirigerar till HTTPS med ett enda rent hopp där det är möjligt.
• Omdirigeringar för kanonisk värd är konsekventa, till exempel från icke-www till www, eller tvärtom.
• Applikationens assets är inte beroende av osäkra http://-URL:er.

Mixed content är mindre vanligt än det brukade vara, men det dyker fortfarande upp i gamla CMS-teman, analyssnippets, inbäddade medier och hårdkodade bildsökvägar.

Steg 3: Börja med en mycket kort max-age

Börja inte med ett år. Börja med fem minuter:

Strict-Transport-Security: max-age=300

Driftsätt det bara på det värdnamn du testar, vanligtvis den kanoniska produktionswebbplatsen. Utelämna includeSubDomains tills vidare.

Testa sedan i riktiga webbläsare och med kommandoradsförfrågningar:

curl -I https://example.com

Du bör se exakt en Strict-Transport-Security-header. Dubbla HSTS-headers från en applikationsserver och en CDN är en vanlig källa till förvirring. Webbläsare tillämpar i allmänhet den effektiva policyn, men människor som felsöker en incident behöver ingen tvetydighet.

Steg 4: Öka gradvis

Om inget går sönder, öka varaktigheten stegvis:

Strict-Transport-Security: max-age=86400

Sedan:

Strict-Transport-Security: max-age=604800

Sedan kanske:

Strict-Transport-Security: max-age=2592000

Ett praktiskt schema är:

• 5 minuter
• 1 dag
• 1 vecka
• 1 månad
• 6 månader eller 1 år

Det finns inget pris för att skynda. Hela poängen med stegvis utrullning är att ge din övervakning, supportinkorg och dina edge cases tid att berätta vad din checklista missade.

Steg 5: Lägg till includeSubDomains först när granskningen är verklig

När varje publik subdomän är redo för HTTPS kan du överväga:

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

Det här är tillfället att vara konservativ. Om en äldre tjänst fortfarande behöver HTTP ska du inte lägga till includeSubDomains på föräldradomänen. Migrera antingen den tjänsten, flytta den till en annan domän eller acceptera att din HSTS-policy måste förbli smalare tills vidare.

Säkerhetsheaders ska spegla verkligheten. De ska inte användas som motivationsaffischer för infrastruktur du hoppas ha senare.

Steg 6: Behandla preload som ett separat projekt

Överväg preload först när allt följande stämmer:

• Domänen och alla subdomäner stöder giltig HTTPS.
• HTTP omdirigerar till HTTPS.
• HSTS-headern använder max-age på minst 31536000 sekunder.
• Headern inkluderar includeSubDomains.
• Headern inkluderar preload.
• Du är säker på att du inte kommer att behöva vanlig HTTP någonstans under domänen.

En preload-redo header ser ut så här:

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

Att skicka in till preload-listan är ett långsiktigt åtagande. Om webbplatsen är en kampanjmikrosajt, en tillfällig produktdomän eller en domän med oklara ägargränser, hoppa över det.

Konfigurationsexempel

Nginx

Använd always så att headern skickas även vid felsvar:

add_header Strict-Transport-Security "max-age=300" always;

Efter att utrullningen är stabil:

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

Apache

Med mod_headers aktiverat:

Header always set Strict-Transport-Security "max-age=300"

Senare:

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

CDN eller edgeplattform

Om din CDN sätter svarheaders, föredra att hantera HSTS på ett enda ställe. Sätt inte en policy vid origin och en annan vid edge om du inte har ett mycket tydligt skäl.

Kontrollera också om CDN:en tillämpar headers på omdirigeringar, cachade fel och anpassade felsidor. En produktionswebbplats är inte bara sitt 200 OK-svar.

Så ångrar du HSTS säkert

Om du behöver inaktivera HSTS, skicka:

Strict-Transport-Security: max-age=0

Men det finns en hake: webbläsaren måste kunna nå webbplatsen över giltig HTTPS för att ta emot den headern. Om HTTPS i sig är trasigt kan användare med en cachad HSTS-policy inte hämta instruktionen som skulle rensa den.

Den vanliga återställningsordningen är därför:

1. Återställ giltig HTTPS.
2. Servera Strict-Transport-Security: max-age=0.
3. Låt den ligga kvar tillräckligt länge för att återkommande användare ska ta emot den.
4. Ta bort eller ersätt headern efter att incidenten är löst.

Om domänen är preloaded räcker det inte att servera max-age=0 för nya webbläsarprofiler. Du behöver också begära borttagning från preload-listan och vänta på att ändringen levereras via webbläsaruppdateringar.

Testchecklista innan du lanserar

Använd den här checklistan innan du ökar max-age eller lägger till includeSubDomains:

• Den kanoniska HTTPS-URL:en returnerar ett giltigt certifikat.
• HTTP omdirigerar till HTTPS.
• Det finns bara en HSTS-header.
• Headern visas på omdirigeringar och felsvar där det är lämpligt.
• Alla publika subdomäner har giltig HTTPS.
• Certifikatförnyelse övervakas.
• Inget kritiskt internt system är beroende av HTTP under samma föräldradomän.
• Preload har diskuterats uttryckligen, inte lagts till av vana.

Lighthouse kan också flagga saknade eller svaga säkerhetsheaders i vissa sammanhang, men det bör inte vara din enda verifieringsmetod. Om du använder det som del av en bredare granskning, läs fynden som signaler snarare än domar; samma förhållningssätt gäller när du läser en Lighthouse-rapport utan att få panik.

<!-- tool-cta:start -->

💡 Prova detta: Före och efter varje HSTS-ändring bör du granska Strict-Transport-Security-svaret med Get Headers för att bekräfta att max-age, includeSubDomains och preload är som du förväntar dig.

<!-- tool-cta:end -->

Integritetsargumentet för HSTS

HSTS framställs ofta som en säkerhetsheader, och det är det. Det har också en integritetsfördel: det minskar risken att en användares första förfrågan läcker över vanlig HTTP på ett opålitligt nätverk.

Det spelar roll på flygplats-Wi-Fi, hotellnätverk, företags gästnätverk och överallt där en användares trafik kan observeras eller modifieras. En vanlig HTTP-förfrågan kan exponera värdnamn, sökväg, cookies utan Secure-flaggan och andra förfrågningsdetaljer. HTTPS är inte magi, men att konsekvent tvinga det tar bort en hel klass av undvikbart läckage.

De bästa HSTS-utrullningarna är ointressanta. De rullas ut långsamt, stöds av tillförlitliga certifikat och är tillräckligt tråkiga för att ingen ska märka dem. Det är exakt vad du vill ha från en header vars felläge kan vara dramatiskt.