Jak funguje Security Audit | Milan Trnka

1. Co audit dělá

Je to pasivní konfigurační audit. Pošle na zadanou URL pár běžných požadavků a vyhodnotí, co je veřejně vidět — nepřihlašuje se, nic neútočí, nic nemění. Proběhne za pár vteřin.

Konkrétně kontroluje:

HTTP bezpečnostní hlavičky — CSP, HSTS, X-Frame-Options, X-Content-Type-Options, Referrer-Policy, Permissions-Policy a další
Cookies — atributy Secure / HttpOnly / SameSite, prefixy
HTML hygienu — inline skripty, event handlery, javascript: odkazy, mixed content, SRI hashe
DNS — DNSSEC, CAA záznamy
Email autentizaci — SPF, DMARC, MTA-STS, TLS-RPT, DANE
TLS — že HTTPS spojení funguje, a jestli se HTTP správně přesměruje na HTTPS
Hosting / infrastrukturu — platforma (CMS / server / CDN), DNS provider, profil webu

⚠️ Auditovat smíš jen domény, které vlastníš nebo k tomu máš oprávnění.

2. Co audit nedělá

Je důležité vědět, kde jsou hranice — aby ses na výsledek nespoléhal víc, než si zaslouží:

Není to penetrační test. Nehledá aplikační zranitelnosti — SQL injection, XSS přes vstupní pole, chyby v business logice, obcházení přihlášení nebo MFA. To umí jen aktivní pentest s písemným souhlasem.
Detaily TLS (cipher suites, řetězec a platnost certifikátu) záměrně neřeší — od toho je SSL Labs, který to dělá lépe. Odkaz na něj (a další specializované nástroje) najdeš přímo v reportu.
Audituje vždy jen jednu konkrétní URL, ne celý web. Bezpečnostní nálezy bývají na podstránkách (blog, formuláře, admin), ne na home page.
Pokročilé / nestandardní hlavičky jako Cross-Origin-Embedder/Resource-Policy (COEP/CORP) nebo Timing-Allow-Origin záměrně neauditujeme — pro běžný web nejsou potřeba a jejich absence není nedostatek (COEP navíc umí rozbít legitimní embedy typu YouTube či Maps).

3. Jak se počítá skóre

Skóre není „kolik testů prošlo". Takový výpočet by srážel kosmetickou drobnost stejně jako kritickou díru — a jeden vážný nález by se schoval mezi desítkami prošlých testů.

Místo toho: skóre začíná na 100 % a každý nález ubere podle své závažnosti.

skóre = 100 − (součet vah nálezů)
Kritické −25 · Doporučené −6 · Kosmetické −1

Navíc platí honest-tool pojistka: bezpodmínečně kritický nález (např. formulář odesílaný přes http://) stropuje skóre pod 50 %. U kontextově kritických nálezů (např. unsafe-inline, jejichž závažnost závisí na profilu webu) se strop plynule utahuje podle dynamičnosti — na hranici profilu bez efektu, u plně dynamické aplikace až na 49. Kritická díra nesmí vypadat jako dobrý web, ale ani jeden hraniční signál nesmí skóre shodit skokem.

U nálezů, jejichž závažnost závisí na typu webu (XSS / clickjacking), se váha plynule škáluje podle profilu webu — viz sekce 6. Celý výpočet je deterministický: žádná umělá inteligence, žádná náhoda, stejný web = stejné skóre.

4. Slovní hodnocení

Slovní verdikt vždy odpovídá číslu — nemůže nastat rozpor typu „20 % = dobrý základ":

Skóre	Hodnocení
`100`	Vynikající	zelená
`85–99`	Velmi dobrý stav	zelená
`70–84`	Dobrý základ	zelená
`50–69`	Co zlepšit	oranžová
`< 50`	Potřebuje opravu	červená

Díky pojistce ze sekce 3 spadne web s bezpodmínečně kritickým nálezem — a každá jasně dynamická aplikace s kritickým nálezem — do červené.

5. Úrovně závažnosti

Každý nález má jednu ze tří úrovní. Řídící pravidlo pro tu nejvyšší:

Kritické = (a) injekce / spuštění kódu, nebo (b) odposlech citlivých dat (hesla, čísla karet). Nic jiného není kritické.

Úroveň	Co to znamená	Příklady
Kritické	Injekce/spuštění kódu nebo odposlech citlivých dat. Řešit hned.	Formulář odesílaný přes `http://`, `javascript:` odkaz, CSP `unsafe-inline` na dynamické aplikaci
Doporučené	Reálné, ale ohraničené riziko nebo obrana do hloubky. Stojí za opravu.	Chybějící CSP / HSTS / X-Frame-Options, chybějící SPF, cookies bez Secure
Kosmetické	Hygiena a best practice bez reálného dopadu. Nice-to-have.	Referrer-Policy, MTA-STS / TLS-RPT, info disclosure, viewport

6. Statický vs. dynamický web

Tentýž nález nemá všude stejnou váhu. unsafe-inline v CSP je kritické na dynamické aplikaci (přihlašování, formuláře, uživatelský obsah), ale na statickém webu bez aplikační plochy je reálná zneužitelnost prakticky nulová — tedy jen kosmetické.

Audit proto — heuristicky, ne přesným měřením — odhadne míru „dynamičnosti" webu z toho, co vidí: nastavuje cookies? má přihlašovací pole nebo formuláře? běží na CMS? jaký má hosting? Výsledkem je konfidence 0–100 %, kterou v reportu vidíš jako badge „Profil webu: statický · jistota 95 %".

Podle této konfidence se plynule škáluje závažnost nálezů třídy XSS / clickjacking — žádný skokový práh. Při nejistotě nástroj raději přitvrdí (bere nález vážněji), aby web nepodcenil.

7. Hranice nástroje

100 % neznamená „neprůstřelný". Skóre měří konkrétní technickou konfiguraci, ne to, jestli je web bezpečný proti všemu. Web se 100 % má čistou základní hygienu — ale pořád může mít zranitelnost v aplikační logice, kterou tenhle typ auditu z principu nevidí.

Same-zone slepá skvrna. Když nástroj audituje doménu hostovanou ve stejné Cloudflare zóně (typicky když si auditem procházíš vlastní web běžící na Cloudflare), subrequest obchází CF edge — věci přidané až na edge (injektované skripty typu Bot Detection / Web Analytics, edge redirecty, WAF) nástroj nevidí. V takovém případě tě report přímo upozorní; pro plný obraz audituj z externí sítě nebo z DevTools prohlížeče (Network + Console).

Pro plný obraz:

V reportu jsou odkazy na specializované validátory (SSL Labs, Mozilla Observatory, Hardenize, CSP Evaluator, …) pro hloubkové ověření jednotlivých oblastí.
Na aplikační vrstvu (vstupy, autentizace, business logika) je potřeba penetrační test.

Potřebuješ jít do hloubky?

Pasivní audit je dobrý první krok. Nabízím konzultaci bezpečnostní konfigurace, code review a posouzení hlaviček a CSP; na skutečný penetrační test nasměruji na ověřeného certifikovaného testera.

Kontaktovat Milana Trnku →