HSTS: princip, funkce a význam pro bezpečnost a SEO na webu

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ý 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 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 snížení rizika ú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í na https:// a server odešle Strict-Transport-Security. Prohlížeč si politiku uloží na dobu určenou max-age.
  2. Vynucení HTTPS: Během platnosti politiky prohlížeč všechny pokusy o HTTP (včetně kliků na http:// odkazy a přímého zadání) automaticky přesměruje 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 vyžadovat HTTPS již při úplně první návštěvě (bez nutnosti předchozí bezpečné odpovědi serveru).

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 v síti nezachytí nezašifrovanou požadavek.
  • Konzistentní šifrování: Všechny URL jsou efektivně „HTTPS-only“, což usnadňuje konfiguraci cookies, CSP a dalších zásad.
  • Nižší riziko chyb uživatelů: 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čování 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 typicky 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 sekund.
  • Subdomény: Musí být uvedeno includeSubDomains.
  • Direktiva preload musí být přítomná 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 dělejte 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šte na 1 den, 1 týden, 1 měsíc, 6–12 měsíců.
  4. Rozšíření na subdomény: Po verifikaci certifikátů na všech subdoménách přidejte includeSubDomains.
  5. Preload fáze: 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. Při HTTP odpovědích dojde k přesměrování a prohlížeč si politiku ukládá z bezpečného kanálu.

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

  • Bezpečné cookies: Nastavte Secure a vhodné SameSite (Lax nebo Strict), aby se neposílaly přes HTTP.
  • CSP a moderní hlavičky: Doplňujte 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ám 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ílově 100 %).

Antivzory a rizika: čemu se vyhnout

  • Předčasný preload: Pokud některá subdoména nepodporuje HTTPS, preload zablokuje přístup (prohlížeč odmítne HTTP).
  • Příliš dlouhý max-age bez testu: Chyba v konfiguraci se bude obtížně vracet zpět – začněte s 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 externí 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í doručení 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, které směřují na vaše subdomény, fungují přes HTTPS a nevyžadují fallback na běžné HTTP.

Testování a audit: kontrolní body před tvrdý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 důvěryhodnost, pokrytí SAN a automatizované obnovování (cron/hook v CI/CD).
  4. RUM a syntetika: 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 hodin), 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: Potřebný, ale sám o sobě nebrání SSL strippingu (první HTTP request stále proběhne). 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 pro riziko „self-DoS“ a náročnou správu. Nepoužívejte.
  • DNS CAA: Doplnková kontrola certifikačních autorit; doporučené pro snížení rizika vydání 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ý krok).
  • Nasazena hlavička HSTS s adekvátním max-age; otestováno v RUM/syntetice.
  • Žádné kritické závislosti na běžném 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ří kostru „secure-by-default“ přístupu. Zavádějte jej postupně, monitorujte metriky a až poté zvažte preload – odměnou bude robustní šifrování bez zbytečných kompromisů či překvapení.