Slik setter du opp HSTS uten å låse deg selv ute

HSTS er enkelt helt til det ikke er det

HTTP Strict Transport Security, vanligvis forkortet til HSTS, forteller nettlesere: «for dette nettstedet, bruk alltid HTTPS.» Når en nettleser mottar headeren over en gyldig HTTPS-tilkobling, husker den regelen så lenge du angir.

Det er nyttig. Det hindrer protokollnedgraderingsangrep, reduserer utilsiktede usikre forespørsler og unngår det klønete øyeblikket der en bruker skriver example.com og kort er innom vanlig HTTP før omdirigering.

Det er også seigt. Hvis du publiserer feil HSTS-policy, kan nettlesere fortsette å håndheve den lenge etter at du har fjernet headeren fra serveren. Det er slik team låser seg ute: ikke nødvendigvis fra sitt eget administrasjonspanel, men fra brukernes nettlesere, underdomener, staging-systemer, gamle endepunkter og glemte tjenester som ikke er klare for tvungen HTTPS.

Målet er ikke å unngå HSTS. Målet er å innføre det som en migrering, ikke som en bryter.

Hva HSTS-headeren faktisk gjør

En typisk HSTS-header ser slik ut:

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

Den har tre viktige deler:

• max-age: hvor lenge, i sekunder, nettleseren skal håndheve HTTPS for denne verten.
• includeSubDomains: om regelen også gjelder for alle underdomener.
• preload: et signal om at du ønsker domenet inkludert i nettlesernes preload-lister.

Nettleseren stoler bare på denne headeren når den mottar den over gyldig HTTPS. Hvis sertifikatet er ugyldig, utløpt eller ikke samsvarer, skal nettleseren ikke godta en ny HSTS-policy fra det svaret.

Når policyen er lagret, oppgraderes fremtidige forsøk på å besøke http://example.com av nettleseren til https://example.com før forespørselen sendes. Det er personverngevinsten: den usikre forespørselen forlater aldri enheten.

Utestengingsscenarioene du bør unngå

De fleste HSTS-feil skyldes ikke hovednettstedet. De skjer i kantene.

1. Et glemt underdomene er ikke klart for HTTPS

includeSubDomains høres ryddig ut, men det er absolutt. Hvis du setter det på example.com, gjelder det for:

• www.example.com
• api.example.com
• old-crm.example.com
• printer-setup.example.com
• staging.example.com
• alt annet under det domenet

Hvis noen av disse vertene ikke kan levere gyldig HTTPS, vil brukere med HSTS-policyen mellomlagret ikke kunne nå dem over HTTP.

2. Et sertifikat utløper

Uten HSTS klikker brukere av og til forbi sertifikatadvarsler. Det er ikke god sikkerhetspraksis, men det skjer.

Med HSTS tillater moderne nettlesere ikke enkel omgåelse av sertifikatfeil for den verten. Det er poenget. Det betyr også at sertifikatfornyelse må være kjedelig, overvåket og testet.

3. Staging eller interne verktøy ligger under produksjonsdomenet

Å legge interne verktøy under *.example.com kan bli smertefullt når overordnet domene bruker includeSubDomains. Hvis disse verktøyene bruker selvsignerte sertifikater, private sertifikatutstedere, gamle TLS-konfigurasjoner eller ingen HTTPS i det hele tatt, vil HSTS avsløre snarveien.

Dette er én grunn til at mange team holder interne og eksperimentelle systemer under et eget domene som har sin egen sikkerhetspolicy.

4. Preload behandles som en rutinemessig avkrysningsboks

HSTS preload er ikke bare et direktiv til. Det betyr at domenet ditt kan leveres inne i nettlesere som kun HTTPS før noen bruker har besøkt nettstedet ditt.

Det lukker «første besøk»-gapet, men det er mye vanskeligere å angre. Fjerning fra preload-lister kan ta uker eller måneder før det når brukerne, avhengig av nettlesernes utgivelsessykluser. Preload passer for stabile, modne domener. Det passer ikke for et nettsted som fortsatt kartlegger underdomenene sine.

En trygg utrullingsplan

Step 1: Audit every hostname you control

Før du setter includeSubDomains, bør du liste opp hvert vertsnavn under domenet. DNS-oppføringer er en start, men ikke hele historien. Sjekk CDN-konfigurasjoner, hosting-dashbord, e-postrelaterte vertsnavn, gamle markedsføringsverktøy, lagringsbøtter og intern dokumentasjon.

For hvert vertsnavn, svar på:

• Serverer det HTTP, HTTPS eller begge deler?
• Er HTTPS-sertifikatet gyldig og automatisk fornyet?
• Omdirigerer det HTTP til HTTPS på en ryddig måte?
• Er det ment å være offentlig?
• Trengs det fortsatt?

Hvis teamet ditt allerede har vaner for feilsøking av headere i produksjon, passer dette naturlig sammen med sjekker av omdirigeringer og headere. Vi dekket den arbeidsflyten i et lite verktøysett for feilsøking av omdirigeringer og HTTP-headere i produksjon.

Trinn 2: Fiks HTTPS før du legger til HSTS

HSTS gjør ikke et ødelagt HTTPS-oppsett sikkert. Det gjør bare HTTPS obligatorisk.

Før du aktiverer det, verifiser:

• TLS-sertifikater dekker de riktige vertsnavnene.
• Sertifikater fornyes automatisk.
• HTTP omdirigerer til HTTPS med ett rent hopp der det er mulig.
• Kanoniske vertsomdirigeringer er konsekvente, for eksempel ikke-www til www, eller motsatt.
• Applikasjonsressurser er ikke avhengige av usikre http://-URL-er.

Blandet innhold er mindre vanlig enn før, men det dukker fortsatt opp i gamle CMS-temaer, analyse-snutter, innebygde medier og hardkodede bildestier.

Trinn 3: Start med en svært kort max-age

Ikke begynn med ett år. Begynn med fem minutter:

Strict-Transport-Security: max-age=300

Rull det ut bare på vertsnavnet du tester, vanligvis det kanoniske produksjonsnettstedet. Utelat includeSubDomains foreløpig.

Test deretter i ekte nettlesere og med kommandolinjeforespørsler:

curl -I https://example.com

Du bør se nøyaktig én Strict-Transport-Security-header. Dupliserte HSTS-headere fra en applikasjonsserver og et CDN er en vanlig kilde til forvirring. Nettlesere bruker som regel den effektive policyen, men mennesker som feilsøker en hendelse trenger ikke tvetydighet.

Trinn 4: Øk gradvis

Hvis ingenting går i stykker, øk varigheten i etapper:

Strict-Transport-Security: max-age=86400

Deretter:

Strict-Transport-Security: max-age=604800

Så kanskje:

Strict-Transport-Security: max-age=2592000

En praktisk plan er:

• 5 minutter
• 1 dag
• 1 uke
• 1 måned
• 6 måneder eller 1 år

Det finnes ingen premie for å skynde seg. Hele poenget med trinnvis utrulling er å gi overvåkingen, support-innboksen og kanttilfellene tid til å fortelle deg hva sjekklisten overså.

Trinn 5: Legg til includeSubDomains først etter en reell revisjon

Når hvert offentlige underdomene er klart for HTTPS, kan du vurdere:

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

Dette er øyeblikket for å være konservativ. Hvis én gammel tjeneste fortsatt trenger HTTP, ikke legg til includeSubDomains på overordnet domene. Enten migrer den tjenesten, flytt den til et annet domene, eller aksepter at HSTS-policyen din må være smalere foreløpig.

Sikkerhetsheadere bør gjenspeile virkeligheten. De bør ikke brukes som motivasjonsplakater for infrastruktur du håper å ha senere.

Trinn 6: Behandle preload som et eget prosjekt

Vurder preload bare når alt dette er sant:

• Domenet og alle underdomener støtter gyldig HTTPS.
• HTTP omdirigerer til HTTPS.
• HSTS-headeren bruker max-age på minst 31536000 sekunder.
• Headeren inkluderer includeSubDomains.
• Headeren inkluderer preload.
• Du er trygg på at du ikke vil trenge vanlig HTTP noe sted under domenet.

En preload-klar header ser slik ut:

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

Innsending til preload-listen er en langsiktig forpliktelse. Hvis nettstedet er et kampanjemikronettsted, et midlertidig produktdomene eller et domene med uklare eierskapsgrenser, hopp over det.

Konfigurasjonseksempler

Nginx

Bruk always slik at headeren også sendes på feilsvar:

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

Etter at utrullingen er stabil:

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

Apache

Med mod_headers aktivert:

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

Senere:

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

CDN eller edge-plattform

Hvis CDN-et ditt setter responsheadere, bør du helst administrere HSTS på ett sted. Ikke sett én policy ved origin og en annen ved edge med mindre du har en svært tydelig grunn.

Sjekk også om CDN-et bruker headere på omdirigeringer, mellomlagrede feil og egendefinerte feilsider. Et produksjonsnettsted er ikke bare 200 OK-svaret sitt.

Slik angrer du HSTS trygt

Hvis du må deaktivere HSTS, send:

Strict-Transport-Security: max-age=0

Men det finnes en hake: nettleseren må lykkes med å nå nettstedet over gyldig HTTPS for å motta den headeren. Hvis HTTPS i seg selv er ødelagt, kan brukere med en mellomlagret HSTS-policy ikke hente instruksen som ville fjernet den.

Den vanlige gjenopprettingsrekkefølgen er derfor:

1. Gjenopprett gyldig HTTPS.
2. Server Strict-Transport-Security: max-age=0.
3. La den være på plass lenge nok til at tilbakevendende brukere mottar den.
4. Fjern eller erstatt headeren etter at hendelsen er løst.

Hvis domenet er preloaded, er det ikke nok å servere max-age=0 for nye nettleserprofiler. Du må også be om fjerning fra preload-listen og vente på at endringen distribueres gjennom nettleseroppdateringer.

Testsjekkliste før du lanserer

Bruk denne sjekklisten før du øker max-age eller legger til includeSubDomains:

• Den kanoniske HTTPS-URL-en returnerer et gyldig sertifikat.
• HTTP omdirigerer til HTTPS.
• Det finnes bare én HSTS-header.
• Headeren vises på omdirigeringer og feilsvar der det er relevant.
• Alle offentlige underdomener har gyldig HTTPS.
• Sertifikatfornyelse overvåkes.
• Ingen kritiske interne systemer er avhengige av HTTP under samme overordnede domene.
• Preload er diskutert eksplisitt, ikke lagt til av vane.

Lighthouse kan også flagge manglende eller svake sikkerhetsheadere i noen sammenhenger, men det bør ikke være den eneste verifiseringsmetoden din. Hvis du bruker det som del av en bredere gjennomgang, les funnene som signaler snarere enn dommer; samme tankesett gjelder når du leser en Lighthouse-rapport uten å få panikk.

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

💡 Prøv dette: Før og etter hver HSTS-endring bør du inspisere Strict-Transport-Security-svaret med Get Headers for å bekrefte at max-age, includeSubDomains og preload er som forventet.

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

Personvernargumentet for HSTS

HSTS omtales ofte som en sikkerhetsheader, og det er det. Det har også en personvernfordel: det reduserer sjansen for at en brukers første forespørsel lekker over vanlig HTTP på et upålitelig nettverk.

Det betyr noe på flyplass-Wi-Fi, hotellnettverk, gjestenettverk i bedrifter og hvor som helst der en brukers trafikk kan observeres eller endres. En vanlig HTTP-forespørsel kan eksponere vertsnavnet, stien, informasjonskapsler uten Secure-flagget og andre forespørselsdetaljer. HTTPS er ikke magi, men å tvinge det konsekvent fjerner en hel klasse med unngåelig lekkasje.

De beste HSTS-utrullingene er uinteressante. De rulles ut sakte, støttes av pålitelige sertifikater og er kjedelige nok til at ingen legger merke til dem. Det er akkurat det du vil ha fra en header der feilmodusen kan være dramatisk.