Proč je web často slabší místo než samotné heslo
Útočníci dnes většinou nezačínají u náhodného zkoušení přístupových údajů. Nejprve si web automatizovaně projdou, zjistí technologii, verze pluginů, otevřené endpointy, admin cesty, chyby v hlavičkách i to, jestli se dá obejít přihlášení přes formulář nebo API. Podle reportu Verizon DBIR se dlouhodobě objevují mezi nejčastějšími příčinami incidentů zranitelnosti aplikací a zneužití přístupových údajů; v praxi se tyto dvě cesty často kombinují.
Pro majitele webu to znamená jediné: nestačí mít „silné heslo“. Pokud běží web na zastaralém WordPressu, používá plugin s veřejně známou chybou nebo vrací detailní chybové hlášky, útočník má stále několik cest dovnitř. A právě tyto slabiny jsou často levnější a rychlejší na zneužití než brute force útok na heslo.
Nejčastější vstupní body: kde weby selhávají nejčastěji
Většina reálných průniků začíná na jednom z těchto míst:
- Neaktualizovaný CMS – typicky WordPress, Joomla, Drupal nebo vlastní redakční systém s odloženými záplatami.
- Zranitelné pluginy a šablony – často mají vyšší riziko než samotné jádro systému.
- Slabě zabezpečené formuláře – kontaktní formuláře, přihlášení, reset hesla, nahrávání souborů.
- API bez autentizace nebo rate limitu – zejména headless řešení, mobilní aplikace a e-commerce integrace.
- Chybně nastavený hosting – otevřené adresáře, sdílené účty, špatná práva souborů, staré PHP verze.
- Úniky přes zálohy a staging – testovací weby s produkčními daty bývají snadný cíl.
Bezpečnostní firmy jako Sucuri nebo Wordfence dlouhodobě upozorňují, že velká část napadených webů má společný jmenovatel: zneužitý plugin, slabé přihlašování nebo kompromitovaný hostingový účet. U WordPressu je problém často v tom, že samotné jádro je relativně dobře udržované, ale ekosystém pluginů je obrovský a kvalita se výrazně liší.
Praktický bezpečnostní audit webu: co zkontrolovat jako první
Pokud chcete web posoudit realisticky, začněte audit v tomto pořadí. Nejde o formální checklist, ale o rychlé odhalení největších děr.
1. Zkontrolujte verze a exponované technologie
Pomocí nástrojů jako Wappalyzer, BuiltWith nebo manuálním průzkumem zjistěte, co web používá. Pokud je veřejně vidět konkrétní verze pluginu nebo frameworku, útočník má výhodu. Stejně tak si ověřte, zda server neprozrazuje zbytečně mnoho informací v hlavičkách nebo chybových stránkách.
2. Otestujte přihlašování a formuláře
U loginu sledujte, zda existuje ochrana proti brute force útokům: rate limit, dočasné blokace, CAPTCHA nebo risk-based ochrana. Přihlašovací formulář by nikdy neměl vracet přesnou informaci typu „uživatelské jméno existuje, ale heslo je špatně“. To útočníkům pomáhá při enumeraci účtů.
3. Prověřte uploady souborů
Nahrávání souborů patří mezi časté slabiny. Povolit by mělo jen přesně definované typy souborů, s kontrolou MIME typu, velikosti a ideálně i antivirovou kontrolou. U obrázků je vhodné soubory znovu přegenerovat na serveru, aby se odstranil škodlivý obsah ukrytý v metadatech nebo polyglot souborech.
4. Podívejte se na přístupová práva
Na hostingu a na serveru zkontrolujte oprávnění souborů. U webových aplikací bývá bezpečný výchozí rámec přibližně 644 pro soubory a 755 pro adresáře; citlivé konfigurační soubory mají být přístupné jen nutnému procesu. Pokud všechno běží pod jedním uživatelem, zvyšuje se dopad incidentu.
5. Projděte zálohy, staging a testovací prostředí
Testovací weby by nikdy neměly být veřejně indexované ani napojené na produkční administraci bez omezení. Zálohy mají být mimo hlavní server, šifrované a pravidelně ověřované obnovou. Mnoho organizací zjistí problém až ve chvíli, kdy zálohu opravdu potřebují.
WordPress, e-commerce a headless weby: rozdílná rizika, stejný výsledek
Riziko se liší podle technologie, ale dopad bývá podobný: útočník může měnit obsah, přesměrovávat návštěvníky, krást data nebo web úplně vyřadit z provozu. U WordPressu je největší problém kombinace pluginů, šablon a lidské nedisciplinovanosti při aktualizacích. U WooCommerce navíc pracujete s objednávkami, adresami, fakturačními údaji a často i platebními integracemi, takže dopad incidentu je výrazně vyšší.
U headless řešení a webů postavených na Next.js nebo podobných technologiích je častým problémem API vrstva. Pokud endpoint vrací příliš mnoho dat, není chráněný tokenem nebo nemá limity na počet požadavků, může dojít k úniku dat nebo k DoS přetížení. Bezpečnost není jen otázka CMS, ale celé architektury.
- WordPress: pravidelně aktualizovat jádro, pluginy i šablony, omezit počet doplňků, používat bezpečnostní plugin a 2FA.
- WooCommerce: chránit administraci, auditovat role uživatelů, hlídat webhooky a platební napojení.
- Headless web: zabezpečit API klíče, nastavit CORS, rate limiting a validaci vstupů.
Minimum, které by měl mít každý web: technická ochrana bez kompromisů
Existuje sada opatření, která by měla být standardem i u menších webů. Nejsou to „nice to have“ prvky, ale základní vrstva obrany.
- HTTPS všude – SSL/TLS certifikát, HSTS a přesměrování na HTTPS bez výjimek.
- 2FA pro administraci – ideálně přes aplikaci nebo hardwarový klíč, ne jen SMS.
- WAF – web application firewall, například Cloudflare, Sucuri nebo ModSecurity.
- Rate limiting – ochrana proti bruteforce, scraping i botům na formulářích a API.
- Content Security Policy – omezení načítání skriptů z cizích domén.
- Security headers – například X-Content-Type-Options, X-Frame-Options, Referrer-Policy.
- Pravidelné zálohy – denní u aktivních webů, s testem obnovy.
Pokud chcete rychlý přehled, použijte Mozilla Observatory, securityheaders.com nebo Qualys SSL Labs. Tyto nástroje sice neodhalí vše, ale velmi dobře ukážou základní nedostatky v konfiguraci.
Monitoring, logy a reakce: bezpečnost není jednorázový úkol
Velká část incidentů se dá zachytit dřív, než způsobí škodu, pokud web skutečně sledujete. Základem jsou logy přístupů, chyb a administrace. U WordPressu nebo podobného CMS je vhodné doplnit plugin nebo službu, která hlídá změny souborů, nové administrátory, neúspěšná přihlášení a podezřelé úpravy obsahu.
Prakticky se vyplatí nastavit:
- upozornění na změny souborů v produkčním webrootu,
- notifikace na nové admin účty a změny rolí,
- monitoring nedostupnosti přes UptimeRobot, Better Stack nebo Pingdom,
- monitoring reputace domény a blacklistů,
- pravidelný sken zranitelností pomocí nástrojů jako Nessus, OpenVAS nebo Snyk u moderních stacků.
Reakční plán by měl být připravený předem: kdo vypne web, kdo obnoví zálohu, kdo komunikuje s hostingem a kdo řeší incident z pohledu GDPR. Pokud web pracuje s osobními údaji, incident není jen technický problém, ale i právní a reputační riziko.
Jak snížit riziko v praxi už během jednoho týdne
Nemusíte hned stavět enterprise bezpečnostní program. Už během několika dní lze zásadně zlepšit stav webu. Největší efekt mívají tyto kroky:
- odstranit nepoužívané pluginy, témata a testovací účty,
- zapnout 2FA pro administrátory a redaktory,
- aktualizovat CMS, šablony a pluginy na poslední stabilní verze,
- omezit přístup do administrace podle IP, pokud to provoz dovolí,
- nasadit WAF a základní ochranu proti botům,
- zkontrolovat zálohy a ověřit jejich obnovu,
- projít formuláře, uploady a API endpointy z pohledu zneužití.
Bezpečný web není ten, který „ještě nebyl napaden“. Bezpečný web je ten, který má menší útočnou plochu, rychle odhalí podezřelé chování a umožní obnovu bez paniky. Přesně to je rozdíl mezi webem, který přežije automatizovaný útok, a webem, který se stane snadným cílem už při prvním skenu.
