HSTS: povinné zabezpečené připojení HTTPS

LLM a generativní AI
Dalimil
HSTS: Vynútené zabezpečené HTTPS pripojenie

HSTS: co je HTTP Strict Transport Security a proč jej aktivovat

HSTS (HTTP Strict Transport Security) je bezpečnostní mechanismus definovaný v RFC 6797, který nutí prohlížeče používat pro danou doménu výhradně protokol HTTPS. Server odešle hlavičku Strict-Transport-Security s parametry, podle kterých si prohlížeč zapamatuje zásadu a následně automaticky přepisuje všechny budoucí pokusy o připojení přes HTTP na HTTPS. Výsledkem je odolnost vůči útokům typu SSL stripping, konzistentní šifrování a nižší riziko úniku citlivých údajů.

Mechanismus fungování: od první návštěvy po „preload“

  1. První bezpečná návštěva: Uživatel se připojí přes https:// a server odešle Strict-Transport-Security. Prohlížeč si zásadu uloží na dobu určenou parametrem max-age.
  2. Vynucení HTTPS: Po dobu platnosti zásady prohlížeč automaticky přepíše všechny pokusy o připojení přes HTTP (včetně kliknutí na odkazy http:// a jejich přímého zadání) na HTTPS ještě před odesláním požadavku.
  3. Seznam HSTS Preload: Pokud je doména zapsána v takzvaném seznamu preload, prohlížeč bude vyžadovat HTTPS už při úplně první návštěvě (bez nutnosti předchozí bezpečné odpovědi).

Direktivy HSTS: max-age, includeSubDomains, preload

  • max-age=<sekundy> – povinný; určuje dobu platnosti zásady. Běžná hodnota: max-age=31536000 (1 rok).
  • includeSubDomains – volitelná direktiva; rozšiřuje zásadu na všechny subdomény (např. www, api, img).
  • preload – volitelná direktiva; signalizuje záměr zapsat doménu do globálního seznamu preload prohlížečů. Pro skutečné zařazení je nutná registrace a splnění podmínek.

Příklad bezpečné hlavičky pro produkční prostředí: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload

Bezpečnostní přínosy: eliminace SSL strippingu a jednotné šifrování

  • Ochrana před MITM: K přepisu HTTP na HTTPS dochází v prohlížeči, takže útočník v síti nezachytí nezašifrovaný požadavek.
  • Konzistentní šifrování: Všechny adresy URL jsou fakticky pouze HTTPS, což usnadňuje konfiguraci cookies, CSP a dalších zásad.
  • Nižší riziko chyb uživatelů: Zadání http:// do adresního řádku nezpůsobí nezabezpečené připojení.

HSTS a SEO/AIO/AEO: rychlost, důvěra a konzistentní indexování

  • Stabilní kanonické adresy: Vynucení HTTPS eliminuje duplicitní verze (http:// vs. https://) a snižuje riziko rozdělení signálů.
  • Vyšší důvěryhodnost: Bezpečné doručování JSON-LD, Open Graph či odpovědí API snižuje šum při parsování vyhledávači a agenty LLM.
  • Výkon: Moderní TLS (1.3) v kombinaci s HTTP/2/HTTP/3 obvykle nezvyšuje latenci; při správně nastaveném CDN je TTFB srovnatelný nebo nižší než u HTTP.

Podmínky pro HSTS Preload a povinnosti po zařazení

  • Povinná doba jednoho roku: Hodnota max-age musí být alespoň 31536000.
  • Subdomény: Musí být uvedena direktiva includeSubDomains.
  • Direktiva preload musí být součástí odpovědi.
  • Platné certifikáty všude: Všechny subdomény musí mít platný certifikát TLS a přesměrování z HTTP na HTTPS.

Upozornění: Odstranění ze seznamu preload může trvat týdny, protože změna se musí dostat do verzí prohlížečů. O zařazení do seznamu preload proto rozhodujte až po stabilizaci infrastruktury.

Doporučený migrační plán: bezpečný postup krok za krokem

  1. Inventarizace domén: Zmapujte apex, www a všechny subdomény; zkontrolujte certifikáty (SAN, SNI), záznamy CAA a automatické obnovování (např. ACME/Let’s Encrypt).
  2. Přesměrování: Nastavte trvalé přesměrování HTTP → HTTPS (301 nebo 308) na úrovni edge/CDN i origin serveru.
  3. Postupné zapnutí HSTS: Začněte konzervativně (např. max-age=300 = 5 minut), sledujte metriky a chyby. Následně zvyšte hodnotu na 1 den, 1 týden, 1 měsíc a 6–12 měsíců.
  4. Rozšíření na subdomény: Po ověření certifikátů na všech subdoménách přidejte includeSubDomains.
  5. Fáze preload: Až bude vše stabilní, přidejte preload a zaregistrujte doménu do seznamu preload.

Konfigurace: webový server, reverzní proxy a CDN

  • Nginx: add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
  • Apache (httpd): Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
  • CDN/Edge: Aktivujte HSTS v konzoli poskytovatele (sekce WAF/SSL) a ověřte, že se hlavička přidává do všech relevantních odpovědí (200/301/308).

Poznámka: Direktivu přidávejte pouze do odpovědí HTTPS. U odpovědí HTTP stejně dojde k přesměrování a prohlížeč si zásadu ukládá z bezpečného kanálu.

Osvědčené postupy: bezpečný a udržitelný provoz

  • Bezpečné cookies: Nastavte příznak Secure a vhodnou hodnotu SameSite (Lax nebo Strict), aby se cookies neposílaly přes HTTP.
  • CSP a moderní hlavičky: Doplňte HSTS o Content-Security-Policy, X-Content-Type-Options: nosniff, Referrer-Policy a Permissions-Policy.
  • HTTP/2 a HTTP/3: Zapněte HTTP/2/3 pro nižší latenci a vyšší odolnost vůči ztrátě paketů.
  • OCSP stapling a moderní TLS: Aktivujte TLS 1.3, stapling OCSP a vhodné sady šifer.
  • Monitoring: Sledujte metriky 4xx/5xx, chyby TLS, expiraci certifikátů a podíl provozu přes HTTPS (cíl: 100 %).

Antivzory a rizika: čemu se vyhnout

  • Předčasné zařazení do preload: Pokud některá subdoména nepodporuje HTTPS, preload zablokuje přístup (prohlížeč odmítne HTTP).
  • Příliš dlouhý max-age bez testování: Chybu v konfiguraci bude obtížné napravit – začněte s krátkou dobou platnosti.
  • Nekonzistentní přesměrování: Zbytečné řetězení http → www → https → www zvyšuje latenci; upřednostněte jednoznačný cíl (např. https://www.example.com) a přímé přesměrování.
  • Zapomenuté subdomény: Je třeba pokrýt certifikáty administrační panely, staré hostitele nebo záznamy CNAME třetích stran.

HSTS a aplikační architektura: SPA, PWA, API

  • SPA/PWA: Service Workery a manifesty doručujte výhradně přes HTTPS; HSTS zajistí, že první stažení SW nebude zranitelné.
  • API a CORS: Při použití includeSubDomains se ujistěte, že všechny hostitele API používají platné TLS. U hlaviček CORS zachovejte konzistenci mezi doménami.
  • Webhooky a třetí strany: Ověřte, že integrační adresy URL směřující na vaše subdomény fungují přes HTTPS a nevyžadují nouzový přechod na běžné HTTP.

Testování a audit: kontrolní body před důsledným zapnutím

  1. Ověření hlaviček: Zkontrolujte Strict-Transport-Security ve všech odpovědích (200/301/308) na hlavních cestách a u statických zdrojů.
  2. Subdomény: Projděte seznam záznamů DNS (A/AAAA/CNAME) a otestujte TLS i přesměrování.
  3. Certifikáty: Ověřte řetězec důvěry, pokrytí SAN a automatické obnovování (cron/hook v CI/CD).
  4. RUM a syntetické testování: Sledujte vliv na TTFB/LCP a chybovost; HTTPS by nemělo zhoršit metriky oproti HTTP.

Příklady správných hlaviček a postupů

  • Počáteční nasazení: Strict-Transport-Security: max-age=86400 (24 h), bez includeSubDomains a bez preload.
  • Stabilizované prostředí: Strict-Transport-Security: max-age=31536000; includeSubDomains.
  • Příprava na preload: Strict-Transport-Security: max-age=31536000; includeSubDomains; preload + registrace do seznamu preload.

HSTS vs. alternativy a doplňky

  • Přesměrování 301/308: Je nezbytné, ale samo o sobě nebrání SSL strippingu (k prvnímu požadavku HTTP dojde). HSTS zajistí přepis ještě před odesláním požadavku.
  • HPKP: Historicky existovalo HTTP Public Key Pinning, ale od této praxe se upustilo kvůli riziku „self-DoS“ a náročné správě. Nepoužívejte ho.
  • DNS CAA: Doplňková kontrola certifikačních autorit; doporučuje se pro snížení rizika vydání neoprávněných certifikátů.

Kontrolní seznam před zapnutím HSTS v produkčním prostředí

  • Všechny domény a subdomény jsou dostupné přes HTTPS s platnými certifikáty.
  • Konzistentní trvalé přesměrování HTTP → HTTPS (jediný krok).
  • Nasazená hlavička HSTS s přiměřenou hodnotou max-age; ověřeno v RUM/syntetických testech.
  • Žádné kritické závislosti na běžném HTTP (interní nástroje, staré vložené skripty).
  • Po stabilizaci přidat includeSubDomains a poté případně preload a doménu zaregistrovat.

HSTS jako základ strategie „HTTPS-by-default“

HSTS je jednoduché, ale velmi účinné opatření, které zvyšuje bezpečnost, důvěru a konzistenci doručování obsahu. V kombinaci s moderním TLS, vhodnými hlavičkami a kvalitním CDN tvoří základ přístupu „secure-by-default“. Zavádějte ho postupně, sledujte metriky a teprve poté zvažte preload – odměnou vám bude robustní šifrování bez zbytečných kompromisů či překvapení.