Kyberbezpečnost pro tvůrce webů: 5 zásadních chyb, kterých se dopouští freelanceři a malé agentury

Web dnes není jen vizitka. Je to vstupní bod k firemním datům, zákaznickým účtům, platebním systémům i reputaci značky. Přesto je kyberbezpečnost stále jednou z nejpodceňovanějších oblastí při vývoji webů – zejména u freelancerů a menších agentur pracující pod časovým tlakem a často bez dedikovaného bezpečnostního specialisty. Níže najdete pět nejčastějších chyb, které vývojáři dělají, a hlavně doporučení, jak se jim vyhnout.

1. Slabé procesy kolem správy přístupů

Správa přístupů je jedna z nejkritičtějších oblastí bezpečnosti. U freelancerů a malých agentur se však často odehrává organicky – hesla bývají uložena různě a často ne bezpečně, přístupy do hostingu sdílí více lidí, FTP se používá jen ze zvyku a po dokončení projektu nikdo neřeší odstranění přístupů bývalých spolupracovníků.

Tento postup je extrémně rizikový. Dle Verizon Data Breach Investigations Report (DBIR) jsou zneužité nebo odcizené přihlašovací údaje jednou z nejčastějších příčin incidentů a slabá nebo kompromitovaná autentizace příčinou více než 50 % prolomení účtů.

Nejčastější chyby ve správě přístupů

• Sdílené účty mezi více lidmi – jeden přístup do hostingu a jeden administrátor WordPressu pro celou agenturu.
• Slabá hesla, znovu používaná hesla, absence 2FA – freelanceři často používají jedno hlavní heslo do hostingu, GitHubu, WordPressu i FTP klienta. V kombinaci s tím, že někdy hesla uchovávají v Excelu nebo v e-mailu, vzniká kritické riziko.
• Používání FTP místo SFTP/FTPS – FTP posílá hesla i data v otevřeném textu. Útočník na stejné síti je může odposlechnout během vteřiny.
• Neodstranění přístupů po dokončení projektu – freelancer odejde z projektu, ale pořád má přihlášení do hostingu, CMS, CDN, e-mailu a DNS. To znamená, že po dvou letech může kdokoliv z bývalých spolupracovníků stále manipulovat s webem klienta.
• Ukládání hesel v plain-textu (notýsek, Excel, e-mail, Messenger) – nejde jen o technickou nezkušenost, je to hlavní vstupní bod pro ransomware i phishing kampaně.

Jak to dělat správně 

• Používejte správce hesel (Bitwarden, 1Password, KeePassXC).
• Povinně zapněte 2FA všude, kde to jde – hosting, DNS, registrátor domény, GitHub/GitLab, WordPress (pomocí pluginu) a zálohovací systém.
• Po předání projektu odstraňte vývojářské účty z produkce.
• Nepoužívejte sdílené účty – každý člen týmu má vlastní přihlášení.

2. „Bezpečnostní dluh“ u CMS – staré pluginy, neaktualizované šablony

U projektů na WordPressu, Joomle, Drupalu nebo jiných CMS systémů se nejčastěji opakuje jeden scénář – web byl dokončený, běží, klient je spokojený a od té chvíle se na něj měsíce nebo roky nesáhne.

Jenže CMS není statická platforma. Je to živý systém, ve kterém každý plugin, šablona nebo modul představuje potenciální vstupní bod útočníka. Pokud se neaktualizují, vzniká bezpečnostní dluh, který se časem stává hlavní příčinou kompromitací.

Podle analýz Wordfence, Sucuri i dat z WPScan Vulnerability Database tvoří neaktualizované pluginy a šablony 60–70 % všech úspěšných útoků na WordPress. Jde tedy o statisticky největší riziko celého ekosystému.

Nejčastější chyby, které tvoří bezpečnostní dluh 

• Nepoužívání aktualizací nebo odkládání update „až bude čas“ – mnohé agentury aktualizace odkládají, protože se obávají rozbití webu. Zranitelnosti jsou veřejně dokumentované a útočníci je masově skenují během hodin od zveřejnění.
• Pluginy, které už vývojář nepodporuje – desítky tisíc pluginů existují pouze jako side-projekt (nedostávají aktualizace, nemají bezpečnostní fixy a mohou být opuštěné i několik let). V praxi pak na webu běží komponenta, jejíž zdrojový kód je známý.
• Staré nebo špatně napsané šablony – neudržované šablony mohou obsahovat vlastní zastaralé jQuery, inline skripty zvyšující riziko XSS, nevalidní HTML nebo nefunkční integraci zabezpečovacích hlaviček. V horších případech šablony obsahují neúmyslné backdoory nebo odesílají data třetím stranám.
• Zbytečně velké množství pluginů – čím víc pluginů, tím větší riziko. Každý plugin je balíček kódu, který může být nedokonalý, opuštěný nebo obsahovat chybu v logice.
• Neexistence prostředí pro testování (staging) – pokud se aktualizace posouvají s obavou, že by mohly rozbít web, signalizuje to chybějící nebo nedostatečně nastavený workflow. Staging umožní otestovat aktualizace bez rizika pro produkční web.

Jak bezpečnostní dluh minimalizovat

• Nastavte automatické aktualizace (alespoň minor a security) – WordPress, Craft CMS, Joomla i Drupal umožňují automatické dílčí aktualizace.
• Sledujte bezpečnostní bulletiny (WPScan, CVE).
• Nepoužívejte pluginy bez dlouhodobé podpory.
• Dělejte alespoň kvartální bezpečnostní audit webu (ideálně 1× měsíčně nebo kvartálně).

3. Špatná práce s veřejnými repozitáři – uniklá hesla a konfigurace

Veřejné repozitáře na GitHubu nebo GitLabu jsou dnes jedním z nejčastějších míst, kde vznikají kritické bezpečnostní incidenty. Stačí jediný commit s API klíčem nebo heslem a údaje jsou prakticky okamžitě odhalitelné – nejen lidmi, ale hlavně automatizovanými roboty, které prohledávají GitHub 24/7.

Dle GitGuardian Annual Secret Leakage Report unikne každý rok více než 10 milionů tajných údajů (tokenů, klíčů, hesel) a naprostá většina právě přes GitHub.

Nejčastější chyby u freelancerů a malých agentur

• Uložení .env do repozitáře – to je nejrychlejší cesta, jak přijít o přístup do databáze, SMTP, AWS/GCP/Azure klíče nebo API tokeny (Stripe, OpenAI, Cloudflare).
• Hardcodované tokeny nebo hesla v kódu – token v JS nebo PHP souboru znamená, že je automaticky viditelný všem, kdo si stáhnou build nebo dev verzi.
• Nevyčištěná historie commitů – i když vývojář odstraní heslo v další verzi, zůstává v historii repozitáře. Útočníci ji běžně procházejí.
• Repo bez kontroly přístupů – přístup „public“ nebo „internal“ umožní bývalým členům týmu nadále číst zdrojový kód.

Jak chyby eliminovat

• Používejte .gitignore správně – ignorovat: .env, /storage, /vendor, node_modules, .vscode, /uploads.
• Tajné hodnoty ukládejte jen v prostředí, nikoli v kódu (například Docker Compose, Vercel/Netlify environmentu, GitHub → Settings → Secrets).
• Nikdy nepoužívejte veřejné repozitáře pro klientské projekty.
• Mějte zapnutý GitHub Secret Scanning a rotujte uniklé klíče.

4. Web bez základního hardeningu – chybějící bezpečnostní hlavičky a špatná konfigurace

Mnoho webů běží sice na HTTPS, ale tím bezpečnost končí. Chybí jim hlavičky, které chrání před běžnými útoky – XSS, Clickjacking, Session Hijacking nebo únik referrerů. 

Projekt OWASP uvádí, že správně nastavené HTTP bezpečnostní hlavičky mohou „zastavit nebo výrazně omezit celou třídu útoků ještě předtím, než zasáhnou aplikaci“.

Nejčastější chyby u hardeningu

• Chybějící Content-Security-Policy (CSP) – bez CSP může útočník spustit na webu vlastní JavaScript. Správná CSP přitom dokáže většinu XSS útoků zablokovat už na úrovni prohlížeče.
• Slabá Strict-Transport-Security (HSTS) – nástroj zaručuje, že web poběží pouze přes HTTPS. Bez ní hrozí downgrade útoky a odchytávání první nezabezpečené návštěvy.
• Chybějící X-Frame-Options/Frame-Ancestors – bez těchto hlaviček může být web vložen do iframe, což umožňuje útoky typu clickjacking.
• Laxní Referrer-Policy – při slabém nebo chybějícím nastavení může prohlížeč odesílat třetím stranám plné URL včetně citlivých parametrů.
• Nepoužitá Permissions-Policy – bez této hlavičky mohou skripty nebo embedované prvky přistupovat k API pro kameru, mikrofon či geolokaci, i když to web nepotřebuje.

Jak hardening nastavit správně

• Používejte bezpečnostní hlavičky.
• Nastavte audit přes nástroje jako Mozilla Observatory, SecurityHeaders.com, Google Lighthouse (kategorie Best Practices).
• Omezte dostupné služby na serveru – vypněte directory indexing, vypněte PHP errors na produkci a zakažte XML-RPC, pokud není nutné.

5. Chybějící monitoring, logování a reakce na incident

Freelanceři často dokončí web, předají ho klientovi a dál ho nikdo nesleduje. Jenže napadený web nemusí spadnout, může tiše rozesílat spam, přesměrovávat návštěvnost, těžit kryptoměnu nebo vkládat škodlivý JS jen některým návštěvníkům (např. jen z mobilních IP). Bez logů a monitoringu se chyba odhalí až ve chvíli, kdy je pozdě.

Dle ENISA Threat Landscape je monitoring a detekci incidentů „kritickou obranou“ proti ransomwaru a kompromitacím webů.

Nejčastější chyby u monitoringu a logování

• Žádné logy, nebo logy nikdo nekontroluje – bez přístupových a chybových logů nelze zjistit, zda k útoku došlo, odkud přišel ani jak se projevil. Web může být napadený týdny, aniž by si toho někdo všimnul.
• Absence upozornění na změny souborů – malware často tiše upraví jen několik PHP souborů nebo přidá backdoor. Bez monitoringu integrity se tyto změny velmi snadno přehlédnou.
• Chybějící monitoring DNS – bez hlídání DNS může útočník změnit A, MX nebo CNAME záznamy, přesměrovat web na jiný server, zachytávat e-maily nebo převzít služby spojené s doménou.
• Neměří se výkon ani provoz – neobvyklé výkyvy v provozu, chybách nebo výkonu jsou často prvním signálem kompromitace a bez monitoringu zůstanou bez povšimnutí.
• Zálohy nejsou oddělené od produkce – pokud jsou zálohy uložené na stejném hostingu, útočník je smaže spolu s webem. Off-site zálohy jsou nezbytné pro rychlou obnovu.

 Co zavést

• Automatické upozornění na změny souborů (například Wordfence, Security Ninja, Sucuri Security, Jetpack Protect nebo integritní nástroje).
• Pravidelné kontroly logů hostingu.
• Ochrana DNS a upozornění (Cloudflare → DNS Change Alerts).
• Zálohy mimo produkční prostředí – objektové úložiště, jiný hosting, snapshoty u poskytovatele.

Doporučení pro freelancery a malé agentury

Prodávat bezpečnost jako službu je jeden z nejefektivnějších způsobů, jak snížit riziko incidentů a zároveň nabídnout klientům přidanou hodnotu. Místo jednorázového předání webu můžete poskytovat měsíční paušál zahrnující aktualizace, monitoring a bezpečnostní dohled. Pro klienta to znamená jistotu, pro vás stabilní a dlouhodobý příjem.

Automatizace je klíčem k tomu, aby se na důležité úkoly nezapomínalo. Automatické aktualizace, pravidelné zálohy, kontrola integrity souborů a nasazení bezpečnostních hlaviček výrazně snižují technický dluh a minimalizují riziko lidské chyby. Čím méně kroků vyžaduje ruční zásah, tím bezpečnější a stabilnější projekt bude.

Staging prostředí by mělo být samozřejmostí. Umožňuje otestovat aktualizace, pluginy i designové úpravy bez rizika, že poškodíte ostrý web. Jestli někdo provádí změny přímo na produkci, výrazně zvyšuje riziko výpadků i bezpečnostních incidentů.

Zavedení základních bezpečnostních standardů pomáhá udržet kvalitu napříč projekty. Rámec OWASP ASVS nabízí jasné postupy pro správu přístupů, validaci vstupů, ukládání tajných údajů nebo pravidelné audity. I částečné převzetí těchto principů má velký dopad na bezpečnost webu.

Nezapomínejte vzdělávat i klienty. Spousta útoků začíná u banálních chyb, jako je posílání přihlašovacích údajů e-mailem nebo instalace náhodných pluginů. Chvilka vysvětlování ušetří hodiny práce při řešení hacku.

A na závěr, bezpečný a stabilní provoz webu je obvykle v lepších rukou firmy než jednotlivce. Firma má tým, procesy, zastupitelnost, smlouvy a odpovědnost. Tvůrce webu zase může dělat to, co mu jde nejlépe, a to tvořit. Provoz, bezpečnost a monitoring je ideální svěřit profesionální správě.

Například CZECHIA.COM nabízí tvorbu webů na míru a jejich správu. Zde se o váš web stará profesionální tým, který má zástupnost, jasná pravidla a nepřestane komunikovat za pár měsíců. Je to cenově dostupné, spolehlivé a hlavně bezpečné řešení pro každého, kdo nechce riskovat, že web bez údržby skončí po letech kompromitovaný.