1. Slabá hesla a chybějící vícefaktorové ověření

Nejčastější vstupní bod útoku bývá překvapivě prostý: administrátorské heslo. Podle bezpečnostních reportů patří prolomené přihlašovací údaje dlouhodobě mezi hlavní příčiny incidentů, protože útočníci využívají automatizované slovníkové útoky a zkoušejí miliony kombinací denně. Pokud má webové rozhraní heslo typu „Admin123“ nebo stejné přihlašovací údaje jako jiné služby, je otázkou času, kdy se někdo dostane dovnitř.

Praktický standard je dnes jasný: pro administraci používat dlouhá unikátní hesla o délce alespoň 14 znaků, ideálně generovaná správcem hesel, a zapnout 2FA/MFA pro všechny účty s vyššími právy. U WordPressu i většiny CMS to lze řešit přes ověřovací aplikaci nebo hardwarový klíč. Přínos je zásadní: i když unikne heslo, útočník bez druhého faktoru neprojde.

  • Zakázat sdílené administrátorské účty.
  • Omezit počet pokusů o přihlášení.
  • Přesměrovat administraci na samostatnou URL nebo chránit IP whitelistem, pokud to provoz dovolí.
  • Pravidelně kontrolovat seznam aktivních uživatelů a mazat nevyužívané účty.

2. Zastaralý CMS, pluginy a šablony

V praxi jde o jednu z nejrizikovějších děr. Web může být napaden i bez chyby v samotném jádru systému – stačí zranitelný doplněk, který nebyl aktualizovaný několik měsíců. U populárních platforem se nové zranitelnosti objevují průběžně a útočníci je dokážou skenovat a automaticky zneužívat během hodin až dnů po zveřejnění.

Například u WordPressu bývá problém v neudržovaných pluginech, které uživatelé instalují „na zkoušku“ a pak je nechají aktivní. Bezpečnostní praxe proto doporučuje mít jen nezbytné rozšíření, aktualizace testovat na stagingu a pravidelně provádět audit. Důležité je také sledovat, zda plugin stále dostává podporu. Pokud ne, je lepší ho nahradit, než čekat na incident.

  • Aktualizovat CMS, pluginy a šablony co nejdříve po vydání bezpečnostní opravy.
  • Odstranit neaktivní pluginy i šablony, nejen je deaktivovat.
  • Vést inventář rozšíření a jejich poslední aktualizace.
  • U kritických webů zvažovat automatické bezpečnostní updaty s dohledem.

3. Chybně nastavená oprávnění a otevřené soubory

Další slabina nevzniká z útoku, ale z konfigurace. Pokud má webové soubory příliš volná oprávnění, může útočník po získání částečného přístupu snadno nahrát škodlivý skript, přepsat konfiguraci nebo si vytvořit trvalou zadní vrátka. Typicky se to stává u serverů, kde jsou adresáře nastavené na 777 nebo kde má proces webserveru zbytečně široká práva.

Správné nastavení práv závisí na technologii, ale obecně platí: soubory by měly mít co nejmenší nutná oprávnění, citlivé konfigurace nesmí být veřejně dostupné a uploadované soubory je třeba izolovat. U webů s uživatelským obsahem je vhodné kontrolovat, zda nelze do upload složky nahrát spustitelný PHP skript nebo jiný nebezpečný formát.

  • Kontrolovat práva souborů a adresářů po každé migraci nebo obnově zálohy.
  • Zakázat spouštění skriptů v upload složkách.
  • U citlivých souborů používat serverovou ochranu proti přímému stažení.
  • Pravidelně testovat, zda se k neveřejným cestám nedá dostat přes přímou URL.

4. Nechráněné formuláře a útoky přes vstupy od uživatelů

Kontaktní formulář, vyhledávání, komentáře nebo přihlášení k newsletteru jsou častým cílem útoků typu SQL injection, XSS nebo spam botů. Pokud web nepoužívá validaci vstupů a výstupní escapování, útočník může vložit škodlivý kód, který se spustí v prohlížeči návštěvníka nebo poškodí databázi. I zdánlivě drobná chyba v jednom poli může znamenat problém pro celý systém.

Moderní web by měl používat serverovou i klientskou validaci, parametrizované dotazy a sanitizaci vstupů. U formulářů má smysl přidat rate limiting, honeypot pole a ochranu proti botům. U veřejných komentářů a formulářů je vhodné nasadit CAPTCHA jen tam, kde je to nutné, protože příliš agresivní ochrana zhoršuje konverze. Cílem je rovnováha mezi bezpečností a použitelností.

  • Používat prepared statements nebo ORM s ochranou proti SQL injection.
  • Escapovat veškerý výstup do HTML.
  • Omezit počet odeslání formuláře z jedné IP nebo zařízení.
  • Logovat podezřelé pokusy o vkládání skriptů a SQL znaků.

5. Chybějící HTTPS, slabé hlavičky a špatná konfigurace serveru

Web bez HTTPS je dnes nejen bezpečnostní problém, ale i reputační a provozní riziko. Bez šifrování může dojít k odposlechu přihlašovacích údajů nebo manipulaci s obsahem během přenosu. Stejně důležité jsou ale i bezpečnostní hlavičky a samotná konfigurace serveru. Pokud chybí například Content-Security-Policy, Strict-Transport-Security nebo ochrana proti clickjackingu, web je zranitelnější vůči běžným třídám útoků.

V praxi je vhodné kontrolovat konfiguraci přes nástroje jako SecurityHeaders.com, Mozilla Observatory nebo audit v rámci OWASP ZAP. U HTTPS je nutné hlídat nejen certifikát, ale i automatické obnovování a přesměrování všech variant domény na jednu kanonickou verzi. Zbytečné jsou i staré TLS protokoly, které mají být vypnuté.

  • Zapnout HTTPS na celé doméně včetně subdomén, kde to dává smysl.
  • Nasadit HSTS, CSP a další bezpečnostní hlavičky podle typu webu.
  • Zakázat staré verze TLS a slabé šifry.
  • Pravidelně testovat konfiguraci po změnách hostingu nebo CDN.

6. Slabé zálohování a pomalá obnova po incidentu

Mnoho firem zjistí problém až ve chvíli, kdy už web nefunguje. Bez záloh se pak řeší nejen oprava, ale i ztráta dat, objednávek nebo obsahu. Z bezpečnostního hlediska nestačí mít „nějakou“ zálohu na stejném serveru. Pokud útočník získá přístup k hostingu, může smazat data i zálohy zároveň. Proto je klíčové držet kopii mimo produkční prostředí.

Osvědčený model je pravidlo 3-2-1: tři kopie dat, na dvou různých médiích, jedna mimo hlavní infrastrukturu. U webů s častými změnami je vhodné denní zálohování databáze a souborů, u e-shopů i častěji. Důležité ale je, aby se záloha skutečně dala obnovit. Test obnovy jednou za měsíc odhalí problémy, které by jinak vyšly najevo až v krizové chvíli.

  • Automatizovat zálohování souborů i databáze.
  • Uchovávat více verzí záloh s časovým odstupem.
  • Oddělit přístup k zálohám od přístupu k produkci.
  • Pravidelně simulovat obnovu na testovacím prostředí.

7. Chybějící monitoring, logování a reakční plán

Poslední slabina je organizační, ale dopad má technický. Web může být kompromitovaný týdny, aniž si toho někdo všimne. Bez monitoringu se z drobného incidentu stává velký problém: útočník může vkládat škodlivý kód, přesměrovávat návštěvníky nebo sbírat data. Logy, alerty a jasný postup reakce jsou proto stejně důležité jako technické zabezpečení.

Pro provoz webu se vyplatí sledovat změny souborů, neobvyklé přihlášení, nárůst chyb 5xx, podezřelé požadavky a změny v DNS nebo konfiguraci. U menších webů stačí kombinace serverových logů, e-mailových alertů a základního bezpečnostního pluginu nebo WAF. U větších projektů je vhodné napojení na SIEM nebo centralizovaný monitoring. Pokud se incident stane, tým by měl vědět, kdo vypne přístup, kdo obnoví zálohu a kdo komunikuje směrem k zákazníkům.

  • Nastavit alerty na změny administrátorských účtů, souborů a DNS.
  • Pravidelně procházet access logy a error logy.
  • Mít připravený kontaktní seznam a postup pro incident response.
  • Po každém incidentu udělat krátký technický rozbor příčiny.

Jak web průběžně držet v bezpečnějším stavu

Bezpečnost webu není jednorázový zásah, ale rutina. V praxi funguje jednoduchý měsíční režim: aktualizace systému a pluginů, kontrola uživatelů, audit práv, ověření záloh, test obnovy a základní sken zranitelností. U kritických webů je vhodné přidat i pravidelný penetrační test nebo externí bezpečnostní audit. Náklady jsou obvykle nižší než ztráty z výpadku, poškozené reputace nebo úniku dat.

Pokud má web provozovateli vydělávat, musí být stejně pečlivě spravovaný jako účetnictví nebo sklad. Rozdíl mezi bezpečným a zranitelným webem často netvoří sofistikovaný útok, ale několik přehlédnutých detailů, které zůstaly otevřené příliš dlouho.