Je váš web bezpečný? Praktický checklist, který odhalí reálné riziko

Úvod: Většina firem si plete funkčnost s bezpečím

Firmy obvykle vyhodnocují svůj web podle toho, zda generuje poptávky a dobře vypadá na mobilu. Bezpečnost se téměř nikdy neověřuje aktivně. To vytváří nebezpečný stav: systém může fungovat perfektně, a přesto být v hloubi architektury plně kompromitovatelný. Tento checklist slouží k rychlému vyhodnocení reality. Nehodnotí pocity, ale technická a procesní fakta.

Jak checklist používat

U každé otázky buďte upřímní. Pokud si nejste jistí, odpověď zní vždy „NEVÍM“.

ANO → Standard splněn.

NE → Definované riziko.

NEVÍM → Kritické riziko (ztráta kontroly).

1. Architektura a izolace dat

Základní bariéra, která rozhoduje o tom, zda útočník po prolomení webu získá i vaše data.

Je databáze fyzicky oddělena od veřejného webu? (Běží v privátní síti?)

Je zamezeno přímému přístupu frontendu k datům? (Existuje API mezivrstva?)

Jsou data jednotlivých klientů od sebe izolována? (Logická či fyzická separace?)

Verdikt: Pokud odpovídáte NE, váš systém má strukturální slabinu, kterou nevykompenzuje žádný firewall.

2. Kontrola kódu a závislostí

V roce 2026 je nejčastějším vektorem útoku dodavatelský řetězec (Supply Chain).

Máte přesný seznam všech externích knihoven a pluginů (SBOM)?

Používáte Subresource Integrity (SRI) pro externí skripty?

Je kód systému pravidelně auditován na přítomnost technického dluhu?

Verdikt: Pokud neznáte své závislosti, spouštíte na svém webu cizí kód bez jakékoliv kontroly.

3. Auditovatelnost a logování

Bezpečnost bez důkazů neexistuje. Pokud nevidíte, co se děje, nemůžete se bránit.

Zaznamenáváte každý přístup k citlivým datům? (Kdo, kdy, co?)

Jsou logy ukládány mimo dosah samotné webové aplikace?

Umíte z dostupných dat rekonstruovat průběh případného incidentu?

Verdikt: Absence logování znamená, že útočník může ve vašem systému operovat týdny, aniž byste si toho všimli.

4. Provozní kontinuita (BCM)

Schopnost vrátit se do funkčního stavu po totální havárii nebo útoku.

Probíhají zálohy automaticky a jsou uloženy v izolovaném prostředí?

Byla v posledních 3 měsících úspěšně otestována obnova systému ze zálohy?

Existuje písemný plán reakce na incident (Incident Response Plan)?

Verdikt: Záloha, která nebyla testována na obnovu, se pro účely bezpečnosti považuje za neexistující.

5. Řízení identit a přístupů

Nejslabším článkem je často uživatelský účet s vysokými právy.

Je pro všechny administrátorské vstupy vyžadováno MFA (vícefaktor)?

Mají dodavatelé (agentury, freelanceři) pouze časově omezený a minimální přístup?

Je pravidelně revidován seznam aktivních uživatelů a jejich oprávnění?

Verdikt: Heslo v roce 2026 nestačí. Bez MFA je váš systém otevřenou knihou pro automatizované útoky.

Vyhodnocení checklistu

Kritické pravidlo „NEVÍM“

Pokud jste u více než dvou otázek odpověděli „NEVÍM“, klasifikuje se stav vašeho webu jako Kritický, bez ohledu na ostatní odpovědi. Neznalost stavu systému je v kyberbezpečnosti horší než identifikovaná chyba – chybu lze opravit, slepotu nikoliv.

Závěr: Bezpečnost není pocit, ale měřitelný stav

Bezpečnost webu není otázkou dojmu, sympatií k dodavateli nebo výše rozpočtu na marketing. Je to soubor splněných technických podmínek a schopnost udržet nad nimi kontrolu. Tento checklist není certifikátem neprůstřelnosti, ale mapou vašich rizik.

Prvním krokem k bezpečnosti není nákup softwaru, ale odvaha podívat se pravdě do očí. Pokud váš web neprošel tímto testem, je čas přestat doufat v náhodu a začít budovat architekturu, která vaše podnikání skutečně ochrání. V roce 2026 je to jediný způsob, jak si udržet důvěru klientů a stabilitu na trhu.