Bezpečný web není jen zámek v prohlížeči. Co často chybí?

HTTPS je nutnost, ale bezpečnost tím teprve začíná

Visací zámek v adresním řádku uklidní uživatele, ale z pohledu webové bezpečnosti řeší jen šifrování přenosu mezi prohlížečem a serverem. To je důležité, protože chrání přihlašovací údaje, formuláře i cookies před odposlechem. Jenže útočníci dnes míří hlavně jinam: na slabá hesla, zastaralé pluginy, špatně nastavená oprávnění, zranitelný kód nebo nezabezpečené administrace.

V praxi se setkávám s tím, že web má certifikát od Let’s Encrypt, ale zároveň běží na staré verzi redakčního systému, má veřejně dostupný administrátorský panel bez omezení IP adres, nefunkční zálohy a žádný monitoring. Takový web je „technicky zabezpečený“ jen na první pohled. Bezpečnost je ve skutečnosti soubor vrstev, ne jeden přepínač.

Nejčastěji chybí aktualizace, záplaty a kontrola komponent

Největší riziko u CMS platforem, zejména WordPressu, nebývá samotný jádro systému, ale pluginy, šablony a doplňky třetích stran. Podle dlouhodobých statistik bezpečnostních firem tvoří zranitelnosti v rozšířeních významný podíl incidentů na webech postavených na open-source CMS. Útočník často nepotřebuje prolomit celý server; stačí mu zneužít jednu starší knihovnu nebo plugin s nedostatečně ošetřeným vstupem.

Praktický postup je jednoduchý, ale musí být disciplinovaný:

• Aktualizujte jádro CMS, pluginy i šablony ideálně do 48 hodin od vydání bezpečnostní záplaty.
• Používejte staging prostředí, kde aktualizaci nejdřív otestujete na rozbití funkcí a layoutu.
• Omezte počet pluginů na minimum; každý další kus kódu je další potenciální slabina.
• Odstraňte nepoužívané komponenty, ne jen je deaktivujte.

Pokud používáte WordPress, vyplatí se pravidelně kontrolovat známé zranitelnosti v databázích jako WPScan Vulnerability Database, Patchstack nebo v bezpečnostních advisorech samotných vývojářů pluginů. U větších webů je dobré mít inventář všech komponent a vlastní aktualizační proces, ne spoléhat na to, že „to někdo jednou klikne“.

Hesla, přístupy a administrace bývají slabším článkem než server

Velká část útoků nezačíná technickou exploatací, ale prostým odcizením přístupu. Slabé nebo opakovaně používané heslo, chybějící dvoufaktorová autentizace a příliš široká oprávnění jsou stále běžná realita. U firemních webů se navíc často sdílí jeden administrátorský účet mezi více lidmi, což je z pohledu auditu i bezpečnosti špatně.

Co nastavit okamžitě:

• 2FA/MFA pro administraci, hosting, e-mail i Git repozitáře.
• Správce hesel jako 1Password, Bitwarden nebo Keeper místo ukládání v prohlížeči a Excelu.
• Role-based access – editor nemá být administrátor, vývojář nemá mít přístup do všeho.
• Oddělené účty pro správu obsahu, vývoj a hosting.

Na úrovni serveru se vyplatí omezit přístup do administrace pomocí IP whitelistu, VPN nebo alespoň rate limitingem. U WordPressu je vhodné změnit výchozí cesty, chránit /wp-admin a /wp-login.php proti brute-force útokům a logovat neúspěšné pokusy. Cloudflare, Sucuri nebo podobné WAF řešení dokážou výrazně snížit objem automatizovaných útoků.

Zálohy nejsou bezpečné, pokud je nikdo netestuje

„Máme zálohu“ je jedna z nejčastějších vět, které slyším před incidentem. Ve skutečnosti ale záloha nemusí být kompletní, nemusí být dostatečně čerstvá, může být uložená ve stejném účtu jako napadený web nebo ji nemusíte umět rychle obnovit. Bezpečná záloha není jen kopie souborů, ale ověřený proces obnovy.

Doporučuji držet se pravidla 3-2-1: tři kopie dat, na dvou různých médiích, jedna kopie mimo primární infrastrukturu. U webů a e-shopů je rozumné zálohovat:

• databázi,
• uploady a média,
• konfiguraci serveru nebo infrastruktury,
• DNS nastavení, pokud je spravujete ručně,
• seznam pluginů, verzí a klíčových nastavení.

U e-shopů je zásadní RPO a RTO: tedy jak velká ztráta dat je ještě přijatelná a jak rychle musí být web obnoven. Pro menší weby bývá minimum denní záloha, u aktivních e-shopů spíš hodinová databázová záloha a denní plná záloha. Zálohy testujte aspoň jednou měsíčně na odděleném prostředí. Teprve tehdy zjistíte, jestli jsou opravdu použitelné.

Bez monitoringu se incident zjistí až přes zákazníka nebo Google

Napadený web často nehlásí nic viditelného. Přesto může posílat spam, přesměrovávat návštěvníky, vkládat škodlivý skript nebo být zařazený na blacklist. Majitel si problému všimne až ve chvíli, kdy mu přestanou chodit poptávky, klesne organická návštěvnost nebo prohlížeč zobrazí varování.

Proto je nutné sledovat několik vrstev signálů:

• Uptime monitoring – například UptimeRobot, Pingdom nebo Better Stack.
• Bezpečnostní sken – Wordfence, Sucuri Scanner, Nessus, OpenVAS podle typu infrastruktury.
• Logy serveru – neobvyklé přístupy, opakované chyby 401/403/500, podezřelé user-agenty.
• Search Console – bezpečnostní problémy, ruční sankce, malware hlášení.
• Google Safe Browsing a blacklisty – kontrola reputace domény a IP.

U větších webů dává smysl nastavit alerty na změny souborů, nové administrátory, podezřelé cron úlohy nebo nečekané úpravy šablon. Pokud web začal náhle posílat spam přes kontaktní formulář nebo generovat stovky odchozích e-mailů, je to často první známka kompromitace. Čím dřív incident zachytíte, tím menší bývá škoda i dopad na SEO.

Formuláře, e-mail a frontend jsou časté vstupní brány útoku

Bezpečnost se netýká jen backendu. Velké množství problémů vzniká v kontaktních formulářích, nahrávání souborů, komentářích nebo ve frontendových skriptech. Pokud formulář nemá ochranu proti spamu a botům, můžete kromě zahlcení databáze otevřít cestu k injektáži nebo zneužití e-mailové infrastruktury. Stejně tak nesprávně ošetřený upload souborů může znamenat nahrání škodlivého skriptu.

Praktická opatření, která mají okamžitý efekt:

• Validace na serveru, ne jen v prohlížeči.
• Omezení typů souborů a kontrola MIME typu i přípony.
• reCAPTCHA nebo alternativy jako hCaptcha či Turnstile u formulářů s vyšším provozem.
• Content Security Policy (CSP) pro omezení načítání cizích skriptů.
• Security headers jako HSTS, X-Content-Type-Options, X-Frame-Options a Referrer-Policy.

U moderních webů na Next.js, headless CMS nebo Jamstack architektuře je výhodou menší plocha útoku, ale neznamená to automatickou bezpečnost. I tam je potřeba chránit API endpointy, tokens, serverless funkce a externí služby. Bezpečný web je systém, kde máte pod kontrolou přístupy, aktualizace, zálohy, monitoring i provozní disciplínu. Zámek v prohlížeči je jen začátek, ne důkaz, že je web skutečně v pořádku.