Co kontrolujeme

Certifikát už není platný

tls.cert_expired

Prohlížeče na takovém webu zobrazí varovnou stránku. Zákazníci web většinou opustí a platby přes něj neprojdou.

Co udělat: Obnovte certifikát u poskytovatele hostingu nebo zapněte automatickou obnovu (ACME / Let’s Encrypt). Po obnově ověřte, že se nový certifikát nasadil na všechny servery za load balancerem.

https://datatracker.ietf.org/doc/html/rfc5280

Certifikát vyprší za méně než 14 dní

tls.cert_expiring_soon

Pokud automatická obnova selže, web během dvou týdnů přestane fungovat. Většina výpadků HTTPS vzniká právě takto.

Co udělat: Zkontrolujte, že automatická obnova běží a má přístup k doméně. Pokud certifikát obnovujete ručně, naplánujte obnovu do konce tohoto týdne.

Certifikát vyprší za méně než 30 dní

tls.cert_expiring_30d

Zatím nic nehoří. Je to ale okamžik, kdy má smysl ověřit, že obnova proběhne sama.

Co udělat: Ověřte funkčnost automatické obnovy. Žádná okamžitá akce není potřeba.

Certifikát je vystavený na dlouhou dobu platnosti

tls.cert_lifetime_long

Certifikační autority zkracují maximální platnost: od 15. 3. 2027 na 100 dní a od 15. 3. 2029 na 47 dní. Dlouhá platnost obvykle znamená ruční obnovu, která v tomto režimu přestane stačit. Není to dnešní chyba, je to upozornění dopředu.

Co udělat: Ověřte, že certifikát obnovujete automaticky (ACME, například Let’s Encrypt). Pokud ho nahráváte ručně, připravte si automatizaci dřív, než zkrácená platnost začne vyžadovat obnovu několikrát ročně.

https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/

Certifikát neplatí pro tuto doménu

tls.hostname_mismatch

Jméno v certifikátu neodpovídá adrese, na které služba běží. Prohlížeč zobrazí varování a návštěvník nepozná rozdíl mezi chybou konfigurace a skutečným útokem.

Co udělat: Nechte vystavit certifikát, který obsahuje tuto doménu (nebo ji doplňte do SAN u stávajícího). Zkontrolujte i přesměrování mezi variantou s www a bez www.

Certifikát není vydaný důvěryhodnou autoritou

tls.self_signed

Vlastnoručně podepsaný certifikát nikdo zvenčí neověří. Pro veřejnou službu to znamená trvalé varování v prohlížeči.

Co udělat: Nasaďte certifikát od veřejné certifikační autority. Pro běžný web stačí bezplatná varianta přes ACME.

Certifikát se nedá ověřit až k důvěryhodné autoritě

tls.chain_untrusted

Server obvykle neposílá mezilehlý certifikát nebo posílá už vypršelý, certifikát vydala autorita, které prohlížeče nevěří, případně certifikát ještě neplatí. Běžné prohlížeče chybějící mezilehlý certifikát často dohledají samy. Aplikace v telefonu a služby, které se k webu připojují automaticky, to dělat nemusí a spojení odmítnou.

Co udělat: Nasaďte na server celý aktuální řetězec: certifikát i mezilehlé certifikáty, které autorita vydává teď (u Let’s Encrypt soubor fullchain.pem, ne cert.pem). Certifikát, který ještě neplatí, nasaďte až od začátku jeho platnosti, nebo si nechte vystavit nový.

Slabý klíč certifikátu

tls.weak_key

RSA klíč pod 2048 bitů nesplňuje současná doporučení a prohlížeče ho postupně přestávají přijímat.

Co udělat: Při příští obnově vystavte certifikát s RSA 2048+ nebo ECDSA P-256.

https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf

Certifikát je podepsaný zastaralým algoritmem

tls.weak_signature

Podpisy SHA-1 a starší se považují za prolomené a novější prohlížeče je odmítají.

Co udělat: Nechte vystavit certifikát s podpisem SHA-256 nebo silnějším.

Server stále přijímá zastaralé TLS 1.0 nebo 1.1

tls.legacy_protocol_supported

Staré verze protokolu mají známé slabiny a jejich podpora je častý nález v auditech i v bezpečnostních dotaznících od zákazníků.

Co udělat: Na webovém serveru nebo load balanceru povolte jen TLS 1.2 a 1.3. Před vypnutím zkontrolujte, že se nepřipojují staré firemní aplikace.

Certifikát je v pořádku

tls.ok

Platný certifikát od důvěryhodné autority, odpovídající doméně.

Co udělat: Nic není potřeba. Datum vypršení hlídáme dál.

HTTP se nepřesměrovává na HTTPS

http.no_https_redirect

Kdo napíše adresu bez https, komunikuje nezabezpečeně. Na veřejné Wi-Fi jde takový provoz odposlechnout i změnit.

Co udělat: Nastavte na serveru trvalé přesměrování (301) z http:// na https:// pro celou doménu včetně varianty s www.

Chybí hlavička HSTS

http.hsts_missing

Bez HSTS se prohlížeč při prvním pokusu může připojit nezabezpečeně, i když přesměrování existuje. HSTS tuto mezeru zavírá.

Co udělat: Přidejte hlavičku Strict-Transport-Security: max-age=31536000; includeSubDomains. Nejdřív ověřte, že všechny subdomény umí HTTPS.

https://datatracker.ietf.org/doc/html/rfc6797

HSTS má velmi krátkou platnost

http.hsts_short_max_age

Krátká hodnota max-age snižuje účinnost ochrany, protože si prohlížeč pravidlo nepamatuje dost dlouho.

Co udělat: Zvyšte max-age na 31536000 (jeden rok), jakmile máte HTTPS stabilní.

Chybí Content-Security-Policy

http.csp_missing

CSP je nejúčinnější obrana proti vloženému cizímu skriptu (XSS) a proti podvrženému obsahu z cizí domény. Bez ní se takový útok projeví v plné síle.

Co udělat: Zaveďte CSP postupně: nejdřív v režimu Content-Security-Policy-Report-Only, vyhodnoťte hlášení a pak přepněte na vynucování.

https://www.w3.org/TR/CSP3/

Chybí X-Content-Type-Options

http.xcto_missing

Bez této hlavičky může prohlížeč odhadovat typ souboru a spustit jako skript něco, co jím být nemá.

Co udělat: Přidejte hlavičku X-Content-Type-Options: nosniff.

Chybí ochrana proti vložení do cizího rámu

http.frame_protection_missing

Cizí web může váš obsah zobrazit ve svém rámu a přelepit ho tak, aby uživatel klikl na něco jiného, než vidí (clickjacking).

Co udělat: Přidejte do CSP direktivu frame-ancestors self, případně hlavičku X-Frame-Options: SAMEORIGIN.

Chybí Referrer-Policy

http.referrer_policy_missing

Prohlížeč může cizím webům posílat celou adresu, ze které uživatel odešel. V adresách bývají interní identifikátory i tokeny.

Co udělat: Přidejte Referrer-Policy: strict-origin-when-cross-origin.

Chybí Permissions-Policy

http.permissions_policy_missing

Hlavička omezuje, které citlivé funkce prohlížeče (kamera, mikrofon, poloha) smí stránka a vložený cizí obsah používat.

Co udělat: Přidejte Permissions-Policy a vypněte funkce, které web nepotřebuje, například camera=(), microphone=(), geolocation=().

Server zveřejňuje přesnou verzi software

http.server_banner_verbose

Verze v hlavičce sama o sobě není zranitelnost, ale útočníkovi ušetří práci při hledání cíle. Skrýt ji je levné.

Co udělat: Omezte hlavičky Server a X-Powered-By na obecnou hodnotu, nebo je vypněte.

Cookie bez příznaku Secure

http.cookie_missing_secure

Takovou cookie prohlížeč pošle i po nezabezpečeném spojení. Pokud jde o přihlašovací cookie, dá se ukrást odposlechem.

Co udělat: Doplňte u všech cookies příznak Secure.

Cookie bez příznaku HttpOnly

http.cookie_missing_httponly

K takové cookie se dostane JavaScript na stránce. Při úspěšném XSS to znamená přímou krádež přihlášení.

Co udělat: Doplňte HttpOnly u cookies, které čtený JavaScript nepotřebuje (typicky přihlašovací).

Cookie bez příznaku SameSite

http.cookie_missing_samesite

Bez SameSite může cizí web vyvolat akci ve vašem jménu (CSRF).

Co udělat: Nastavte SameSite=Lax, u citlivých operací SameSite=Strict.

Bezpečnostní hlavičky jsou nastavené

http.headers_ok

Všechny sledované hlavičky jsou přítomné v doporučené podobě.

Co udělat: Nic není potřeba.

Doména nemá SPF záznam

dns.spf_missing

Bez SPF si kdokoli může poslat e-mail z vaší adresy. To je nejčastější způsob, jak útočník navede účetní na falešnou fakturu.

Co udělat: Přidejte do DNS TXT záznam SPF, který vyjmenuje vaše odesílací servery, a ukončete ho -all. Pokud z domény e-maily neposíláte vůbec, použijte v=spf1 -all.

https://datatracker.ietf.org/doc/html/rfc7208

SPF nekončí striktním pravidlem -all

dns.spf_permissive_all

Mírné pravidlo znamená, že podvržený e-mail projde, jen se označí. Ochrana tím ztrácí většinu účinku.

Co udělat: Po kontrole, že máte v SPF všechny legitimní odesílatele (včetně rozesílek a CRM), přepněte na -all.

Doména má více SPF záznamů

dns.spf_multiple_records

Více SPF záznamů je podle standardu chyba. Přijímající servery vyhodnotí SPF jako neplatné, takže ochrana nefunguje vůbec.

Co udělat: Sloučte všechny SPF záznamy do jednoho TXT záznamu v=spf1 ...

Doména nemá DMARC záznam

dns.dmarc_missing

DMARC říká přijímajícím serverům, co udělat s podvrženým e-mailem, a posílá vám přehled o tom, kdo se za vás vydává. Bez něj nemáte ani ochranu, ani zprávu o zneužití.

Co udělat: Přidejte TXT záznam na _dmarc.vasedomena.cz. Začněte na v=DMARC1; p=none; rua=mailto:..., vyhodnoťte reporty a postupně zpřísněte na p=quarantine a p=reject.

https://datatracker.ietf.org/doc/html/rfc7489

DMARC je jen v režimu monitorování (p=none)

dns.dmarc_policy_none

Režim none sbírá data, ale podvržený e-mail nezastaví. Pro skutečnou ochranu je potřeba dojít na quarantine nebo reject.

Co udělat: Vyhodnoťte DMARC reporty, doplňte chybějící legitimní odesílatele do SPF a DKIM a pak zpřísněte politiku.

Doména nemá CAA záznam

dns.caa_missing

CAA omezuje, které certifikační autority smí pro vaši doménu vystavit certifikát. Snižuje to riziko, že někdo získá certifikát na vaše jméno.

Co udělat: Přidejte CAA záznam s autoritami, které skutečně používáte, například 0 issue "letsencrypt.org".

https://datatracker.ietf.org/doc/html/rfc8659

Doména nemá MX záznam

dns.mx_missing

Na doménu nelze doručit e-mail. Pokud je to záměr, je to v pořádku. Pokud ne, přicházíte o zprávy.

Co udělat: Pokud má doména přijímat e-maily, doplňte MX záznamy. Pokud ne, doplňte alespoň v=spf1 -all a DMARC p=reject, aby se za vás nedalo posílat.

DMARC vynucuje politiku jen na část zpráv (pct<100)

dns.dmarc_pct_partial

Parametr pct určuje, u jakého podílu zpráv se politika uplatní. Zbytek projde, jako by DMARC nebyl. Nová verze standardu (RFC 9989, DMARCbis) navíc pct ruší, takže postupné zavádění přes pct brzy přestane fungovat.

Co udělat: Jakmile ověříte, že legitimní pošta prochází, nastavte pct=100 (nebo parametr odeberte, výchozí hodnota je 100). Politiku p ponechte na quarantine nebo reject.

https://www.rfc-editor.org/rfc/rfc9989

DMARC výslovně vypíná ochranu subdomén

dns.dmarc_subdomain_unprotected

Doména vynucuje DMARC, ale parametrem sp=none nebo np=none ho pro subdomény vypíná. Útočník pak může posílat podvržené zprávy z takové subdomény, například faktura@ucetni.vase-domena.cz. Právě tudy běží kampaně typu SubdoMailing. Když sp ani np v záznamu nejsou, subdomény přebírají hlavní politiku p a tento nález nevzniká.

Co udělat: Změňte sp=none a np=none na quarantine nebo reject, nebo parametry odeberte, aby subdomény převzaly hlavní politiku. Pokud přes některou subdoménu legitimně odesíláte, dejte jí vlastní DMARC záznam.

https://www.rfc-editor.org/rfc/rfc9989

Chybí MTA-STS pro příchozí poštu

dns.mta_sts_missing

MTA-STS říká odesílajícím serverům, že k vám mají doručovat jen přes ověřené šifrované spojení. Bez něj lze doručení zprávy odposlechnout nebo podstrčit přes nešifrované spojení (downgrade útok). Týká se to jen domén, které přijímají e-mail.

Co udělat: Zveřejněte TXT záznam _mta-sts s identifikátorem politiky a vystavte politiku na https://mta-sts.vase-domena/.well-known/mta-sts.txt. Začněte v režimu testing a po ověření přepněte na enforce.

https://datatracker.ietf.org/doc/html/rfc8461

Chybí TLS-RPT pro hlášení o doručování pošty

dns.tls_rpt_missing

TLS-RPT zajistí, že vám odesílající servery pošlou hlášení, když selže šifrované doručení na vaše servery. Bez něj se o problémech s doručováním pošty nedozvíte. Týká se jen domén, které přijímají e-mail.

Co udělat: Zveřejněte TXT záznam _smtp._tls s adresou (rua=mailto:...), na kterou se mají hlášení posílat. Hlášení neobsahují obsah zpráv, jen počty úspěšných a neúspěšných spojení.

https://datatracker.ietf.org/doc/html/rfc8460

DNS hygiena je v pořádku

dns.ok

SPF, DMARC i CAA jsou nastavené v doporučené podobě.

Co udělat: Nic není potřeba.

Chybí security.txt s kontaktem pro hlášení zranitelností

web.security_txt_missing

security.txt říká, kam nahlásit bezpečnostní chybu. Bez něj neví nálezce, komu zavolat, a čas do opravy se prodlužuje. Od 11. 12. 2027 je kontaktní místo pro hlášení zranitelností povinné pro výrobce podle nařízení CRA.

Co udělat: Zveřejněte soubor na https://vase-domena/.well-known/security.txt podle RFC 9116. Minimálně vyplňte pole Contact (e-mail nebo formulář) a Expires (datum, do kdy soubor platí).

https://datatracker.ietf.org/doc/html/rfc9116

security.txt nemá povinné pole Expires

web.security_txt_no_expires

RFC 9116 vyžaduje pole Expires. Bez něj nálezce nepozná, zda jsou kontakty stále aktuální, a může se spolehnout na zastaralé údaje.

Co udělat: Doplňte do security.txt řádek Expires s datem v budoucnosti (například za rok) ve formátu podle ISO 8601 a při obnově ho posouvejte.

https://datatracker.ietf.org/doc/html/rfc9116

security.txt už není platný (prošlé Expires)

web.security_txt_expired

Pole Expires je v minulosti, takže soubor se podle RFC 9116 má považovat za neplatný. Kontakty v něm mohou být zastaralé a hlášení o zranitelnosti k vám nedorazí.

Co udělat: Zkontrolujte, že kontakt v security.txt je stále funkční, a posuňte pole Expires do budoucnosti. Zvažte automatické připomenutí před vypršením.

https://datatracker.ietf.org/doc/html/rfc9116

robots.txt neřeší AI roboty

web.ai_crawler_policy_missing

Váš robots.txt nemá žádné pravidlo pro roboty, kteří sbírají obsah pro jazykové modely (GPTBot, ClaudeBot, Google-Extended a další). Není to chyba, je to rozhodnutí: váš obsah mohou tito roboti číst a používat, dokud jim to nezakážete.

Co udělat: Pokud chcete přístup AI robotů omezit nebo povolit vědomě, doplňte do robots.txt pravidla pro konkrétní User-agent. Tegmia jen hlásí, že žádné pravidlo nemáte, a nedoporučuje přístup zakázat.

https://www.rfc-editor.org/rfc/rfc9309

Veřejné soubory jsou v pořádku

web.ok

security.txt má platný kontakt i datum. robots.txt buď má pravidlo pro AI roboty, nebo na webu není; co přesně platí, říká důkaz u zjištění.

Co udělat: Nic není potřeba.

Software webu má zveřejněnou zranitelnost

tech.known_vulnerability

Verze softwaru, kterou server sám uvádí, se objevuje ve veřejné databázi známých zranitelností NVD. Útočníci tyhle databáze procházejí stejně jako my. Neznamená to jistě, že je váš web zranitelný: poskytovatelé hostingu často doplňují opravy, aniž by změnili číslo verze.

Co udělat: Zeptejte se poskytovatele hostingu nebo správce webu, jestli je software aktuální a jestli je tahle zranitelnost opravená. Pokud ne, nechte ho aktualizovat na podporovanou verzi. Zvažte také, aby server přesnou verzi v hlavičkách vůbec neuváděl.

https://nvd.nist.gov/

Web běží na verzi s čerstvou kritickou chybou

tech.advisory_affected

Server sám uvádí verzi, kterou výrobce v aktuálním bezpečnostním oznámení označil za zranitelnou. U takových chyb útočníci začínají hledat zranitelné weby během dnů. Opravu mohl hosting doplnit i bez změny čísla verze, proto jde o vysokou pravděpodobnost, ne jistotu.

Co udělat: Hned požádejte hosting nebo správce webu o aktualizaci alespoň na opravenou verzi uvedenou ve zjištění, nebo o potvrzení, že oprava už je nasazená. Pokud to nejde hned, zvažte dočasné omezení webu.

Pro software webu vyšla kritická oprava, jestli ji web má, nevíme

tech.advisory_unverified

Poznali jsme, že web používá software, pro který výrobce právě vydal důležitou bezpečnostní opravu. Verzi server neprozrazuje, nebo ji uvádí v podobě, podle které se to posoudit nedá (sestavení od distribuce). Zvenčí proto nepoznáme, jestli je oprava nasazená. To může zjistit jen váš hosting nebo správce.

Co udělat: Zjistěte verzi v administraci hostingu nebo od správce a zadejte ji do našeho testu. Za pár vteřin uvidíte, jestli je opravená. Pokud ne, nechte ji aktualizovat.

Verze WordPressu má známé bezpečnostní chyby

tech.wordpress_insecure

WordPress.org sám tuto verzi vede jako nezabezpečenou: vyšla pro ni bezpečnostní oprava, kterou web nemá. Chyby ve starých verzích WordPressu útočníci hledají automaticky.

Co udělat: V administraci WordPressu otevřete Nástěnka → Aktualizace a aktualizujte jádro. Předtím si udělejte zálohu.

Plugin webu není v nejnovější verzi

tech.component_outdated

Verze pluginu, kterou web prozrazuje v souborech, které načítá, nebo v kódu stránky, je starší než poslední vydání v adresáři WordPress.org. Opravy chyb a bezpečnostní záplaty přicházejí s novými verzemi.

Co udělat: V administraci WordPressu otevřete Pluginy a plugin aktualizujte. Čísla verzí u souborů může upravit cache plugin, proto verzi ověřte přímo v administraci.

Web používá starou knihovnu jQuery se známými chybami

tech.jquery_vulnerable

jQuery starší než 3.5.0 má zveřejněné chyby CVE-2020-11022 a CVE-2020-11023, kterými lze za určitých okolností vložit do stránky cizí skript.

Co udělat: Aktualizujte jQuery alespoň na 3.5.0, nejlépe na poslední verzi. Starší doplňky mohou potřebovat úpravu, proto to svěřte tomu, kdo web spravuje.

Rozpoznaný software webu

tech.inventory

Přehled softwaru, který web sám prozrazuje v hlavičkách, v kódu úvodní stránky a v souborech, které načítá. Na něm stojí hlídání nových zranitelností: když se pro tuto verzi objeví nová, uvidíte ji jako nové zjištění.

Co udělat: Nic není potřeba. Pokud server uvádí přesné verze, zvažte jejich skrytí.