HSTS: vynucené zabezpečené připojení přes HTTPS

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

HSTS (HTTP Strict Transport Security) je bezpečnostní mechanismus definovaný v RFC 6797, který vynucuje v prohlížečích používání výhradně protokolu HTTPS pro danou doménu. Server odešle hlavičku Strict-Transport-Security s parametry, podle kterých si prohlížeč uloží politiku 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 dat.

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

  1. První bezpečná návštěva: Uživatel se připojí na https:// a server pošle hlavičku Strict-Transport-Security. Prohlížeč si politiku uloží na dobu určenou parametrem max-age.
  2. Vynucení HTTPS: Během platnosti politiky prohlížeč všechny pokusy o HTTP (včetně kliknutí na http:// odkazy a přímého zadání) automaticky přemapuje na HTTPS ještě před odesláním požadavku.
  3. HSTS Preload seznam: Pokud je doména zapsána v tzv. preload listu, prohlížeč bude požadovat HTTPS již při úplně první návštěvě (bez potřeby předchozí bezpečné odpovědi).

Direktivy HSTS: max-age, includeSubDomains, preload

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

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

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

  • Ochrana před MITM: Přepis HTTP na HTTPS probíhá v prohlížeči, takže útočník na síti nezachytí nezašifrovanou požadavku.
  • Konzistentní šifrování: Všechny URL jsou efektivně „HTTPS-only“, což usnadňuje konfiguraci cookies, CSP a dalších pravidel.
  • Snížení rizika uživatelských chyb: Zadání http:// v adresním řádku nezpůsobí nezabezpečené spojení.

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ů.
  • Lepší důvěra: Bezpečné doručení JSON-LD, Open Graph či API odpovědí snižuje šum při parsování vyhledávači a LLM agenty.
  • Výkon: Moderní TLS (1.3) v kombinaci s HTTP/2/HTTP/3 obvykle nezhoršuje latenci; při správné CDN je TTFB srovnatelný nebo nižší než u HTTP.

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

  • Povinný rok: max-age minimálně 31536000.
  • Subdomény: Musí být uvedeno includeSubDomains.
  • Direktiva preload musí být přítomna v odpovědi.
  • Platné certifikáty všude: Všechny subdomény musí mít platný TLS certifikát a přesměrování z HTTP na HTTPS.

Upozornění: Odstranění z preload seznamu může trvat týdny, protože jde o distribuci do verzí prohlížečů. Rozhodnutí pro preload proto provádějte 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), CAA záznamy a automatizované obnovování (např. ACME/Let’s Encrypt).
  2. Redirecty: Nastavte trvalé přesměrování HTTP → HTTPS (301 nebo 308) na úrovni edge/CDN i originu.
  3. Postupné zapnutí HSTS: Začněte konzervativně (např. max-age=300 = 5 minut), sledujte metriky a chyby. Následně zvyšujte na 1 den, 1 týden, 1 měsíc, 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. Preload fáze: Teprve až když je vše stabilní, přidejte preload a doménu zaregistrujte do preload seznamu.

Konfigurace: web 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 (WAF/SSL sekce) a ověřte, že se hlavička přidává na všechny relevantní odpovědi (200/301/308).

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

Nejlepší praktiky: bezpečný a udržitelný provoz

  • Bezpečné cookies: Nastavte Secure a adekvátní SameSite (Lax nebo Strict), aby se 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 lepší odolnost vůči ztrátě paketů.
  • OCSP stapling a moderní TLS: Aktivujte TLS 1.3, stapling OCSP a vhodné cipher suites.
  • Monitoring: Sledujte metriky 4xx/5xx, TLS chyby, expiraci certifikátů a procento HTTPS provozu (cíl: 100%).

Antivzory a rizika: čemu se vyhnout

  • Předčasný preload: Pokud nějaká subdoména nepodporuje HTTPS, preload zablokuje přístup (prohlížeč odmítne HTTP).
  • Příliš dlouhý max-age bez testování: Chyba v konfiguraci se obtížně vrací zpět – začínejte krátkým TTL.
  • Nejednotná přesměrování: Zbytečné řetězení http → www → https → www zvyšuje latenci; preferujte jednoznačný cíl (např. https://www.example.com) a přímý redirect.
  • Zapomenuté subdomény: Administrativní panely, staré hosty nebo třetí strany CNAME musí být pokryty certifikáty.

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í načtení SW nebude zranitelné.
  • API a CORS: Při includeSubDomains se ujistěte, že všechny API hosty používají platný TLS. Pro CORS hlavičky zachovejte konzistenci mezi doménami.
  • Webhooks a třetí strany: Ověřte, že integrační URL směřující na vaše subdomény fungují přes HTTPS a nevyžadují fallback na plain HTTP.

Testování a audit: kontrolní body před finálním zapnutím

  1. Ověření hlaviček: Zkontrolujte Strict-Transport-Security ve všech odpovědích (200/301/308) hlavních cest a statických assetů.
  2. Subdomény: Projděte seznam DNS záznamů (A/AAAA/CNAME) a otestujte TLS i přesměrování.
  3. Certifikáty: Validujte řetězec důvěry, pokrytí SAN a automatizované obnovování (cron/hook v CI/CD).
  4. RUM a syntetické testy: Sledujte dopad 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í rollout: Strict-Transport-Security: max-age=86400 (24 h), bez includeSubDomains, 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 preload seznamu.

HSTS vs. alternativy a doplňky

  • 301/308 redirect: Nutný, ale sám o sobě nebrání SSL strippingu (k prvnímu HTTP requestu dojde). HSTS zajistí přepis ještě před odesláním požadavku.
  • HPKP: Historicky existovalo HTTP Public Key Pinning, ale bylo opuštěno kvůli riziku „self-DoS“ a složité správě. Nepoužívejte.
  • DNS CAA: Doplňková kontrola certifikačních autorit; doporučené pro snížení rizika vystavení neoprávněných certifikátů.

Checklist před produkčním zapnutím HSTS

  • Všechny domény a subdomény dostupné přes HTTPS s platnými certifikáty.
  • Konzistentní trvalé přesměrování HTTP → HTTPS (jediný skok).
  • Nasazená hlavička HSTS s adekvátním max-age; otestováno v RUM/syntetice.
  • Žádné kritické závislosti na plain HTTP (interní nástroje, staré embed skripty).
  • Po stabilizaci přidání includeSubDomains, následně volitelně preload a registrace.

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

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í CDN tvoří páteř „secure-by-default“ přístupu. Zavádějte ho postupně, monitorujte metriky a až poté zvažte preload – odměnou bude robustní šifrování bez zbytečných kompromisů či překvapení.