Bezpečnost webových aplikací není jen téma pro vývojáře. Když dnes provozujete e-shop, klientský portál, rezervační systém nebo interní aplikaci, máte na jednom místě firemní data, kontakty zákazníků i přístupy do dalších systémů. Útočník nepotřebuje znát vaši firmu jménem — automatizovaní roboti zkoušejí zranitelnosti plošně a najdou si i malou aplikaci, o které byste řekli, že nikoho nezajímá.
Dobrá zpráva je, že drtivá většina problémů nevzniká kvůli geniálním hackerům, ale kvůli zanedbaným základům — neaktualizovanému systému, slabému heslu nebo chybějící záloze. V tomto článku projdeme osm oblastí bezpečnosti webových aplikací, které byste měli mít pod kontrolou. Vysvětlíme je lidsky, bez zbytečného žargonu, abyste jako majitel nebo provozní manažer věděli, na co se ptát svého dodavatele a kde hledat slabá místa.
1. HTTPS a šifrovaný přenos dat
HTTPS je první a nejviditelnější vrstva bezpečnosti. Zajišťuje, že data putující mezi prohlížečem návštěvníka a vaším serverem jsou šifrovaná a nikdo je po cestě nepřečte ani nepodvrhne. Poznáte ho podle zámečku v adresním řádku a adresy začínající https://. Bez něj může útočník na sdílené Wi-Fi odposlechnout přihlašovací údaje nebo platební informace.
Dnes je HTTPS standard, který očekává prohlížeč i Google. Certifikát se dá pořídit i zdarma (např. Let's Encrypt), takže důvod ho nemít prakticky neexistuje. Důležité je, aby se obnovoval automaticky — vypršelý certifikát návštěvníky odradí varovnou hláškou a může na pár hodin podlomit důvěru ve váš web.
Tip: Ověřte si, že se na HTTPS přesměrovává i verze bez „www“ a stará http adresa. Jinak může část návštěvníků a starých odkazů končit na nezabezpečené variantě.
2. Pravidelné aktualizace a záplaty
Většina úspěšných útoků míří na známé, dávno opravené zranitelnosti — jen na systémy, které je nikdo nezáplatoval. Týká se to nejen vlastní aplikace, ale i jejího okolí: serveru, databáze, knihoven a u webů postavených na CMS také jádra a doplňků. Typicky bývají nejrizikovější právě pluginy a šablony ve WordPressu, na které se rychle zapomene.
Aktualizace ale nejsou bezmyšlenkovité „kliknout na vše a doufat“. V praxi se vyplatí mít testovací prostředí, kde se nová verze nejdřív vyzkouší, než se nasadí do ostrého provozu. Tím předejdete situaci, kdy bezpečnostní záplata rozbije objednávkový formulář. Právě proto je rozumné mít aktualizace součástí dlouhodobé správy a rozvoje aplikací, ne nárazové akce jednou za rok.
3. Zálohy a obnova provozu
Záloha je vaše pojistka pro chvíli, kdy všechno ostatní selže — ať už kvůli útoku ransomwarem, chybě při aktualizaci, nebo prostě smazanému záznamu. Klíčová otázka nezní „zálohujeme?“, ale „dokážeme se ze zálohy reálně obnovit a jak rychle?“. Záloha, kterou nikdo nikdy nezkusil obnovit, je jen falešný pocit jistoty.
- Automatizace — zálohy běží samy podle plánu, ne když si někdo vzpomene.
- Více kopií na různých místech — alespoň jedna mimo hlavní server, ideálně i offline nebo v jiné lokalitě.
- Pravidelné testy obnovy — minimálně občas reálně zkusit data vrátit zpět.
- Rozumná historie — držet i starší zálohy, protože poškození dat si někdy všimnete až po pár dnech.
Dobrá praxe je řídit se pravidlem 3-2-1: tři kopie dat, na dvou různých typech úložiště, z toho jedna mimo lokalitu. Nezní to složitě a v praxi rozhoduje o tom, jestli výpadek zvládnete za hodinu, nebo za týden.
4. Řízení přístupů a silná autentizace
Velká část incidentů nezačíná u kódu, ale u přihlašování. Slabé nebo opakovaně použité heslo, sdílený administrátorský účet, bývalý zaměstnanec, kterému nikdo nezrušil přístup — to všechno jsou typické a přitom snadno řešitelné mezery. Platí jednoduché pravidlo: každý má vidět a měnit jen to, co opravdu potřebuje ke své práci.
Dvoufaktorové ověření
Dvoufaktorové ověření (2FA) je dnes jedna z nejúčinnějších a nejlevnějších ochran. I když útočník získá heslo, bez druhého faktoru (kód z aplikace, potvrzení v telefonu) se nedostane dál. U administrátorských a citlivých účtů by mělo být samozřejmostí.
Role a oprávnění
U aplikací na míru se vyplatí navrhnout přístupová práva podle rolí (účetní, skladník, manažer, správce) hned od začátku. Pro přihlašování přes ověřené poskytovatele a propojení s dalšími systémy se používá standard OAuth 2.0, který umožní bezpečné přihlášení bez sdílení hesel mezi službami. Téma přístupů jde ruku v ruce s API integracemi, kde je správné nastavení oprávnění naprosto zásadní.
5. Validace vstupů (XSS, SQL injection a spol.)
Tady se dostáváme k jádru toho, čemu se odborně říká bezpečnost na úrovni aplikace. Zní to děsivě, ale princip je jednoduchý: nikdy nedůvěřujte tomu, co přijde z formuláře nebo z internetu. Každý vstup od uživatele se musí zkontrolovat a ošetřit, než se s ním začne pracovat. Mezinárodní komunita OWASP dlouhodobě sleduje nejčastější chyby a dvě z nich potkáte nejčastěji.
SQL injection — útok na databázi
Představte si přihlašovací formulář, do kterého útočník místo jména napíše šikovně sestavený text. Pokud aplikace vstup slepě vloží do databázového dotazu, může útočník databázi přimět vypsat cizí data nebo je smazat. Obrana je dobře známá — používat tzv. parametrizované dotazy, kde se vstup nikdy nemíchá s příkazem. Dnešní frameworky jako .NET nebo Node.js to umí, jen se to musí důsledně dodržovat.
XSS — podvržený skript v prohlížeči
Cross-site scripting (XSS) nastane, když aplikace zobrazí cizí vstup bez ošetření a do stránky se tak propašuje cizí kód. Ten pak může běžet v prohlížeči vašich návštěvníků a třeba krást jejich přihlášení. Řešením je správně „očistit“ a zakódovat vše, co se vykresluje na stránku. U moderních knihoven jako React nebo Vue.js je část ochrany zabudovaná, ale spolehnout se na to slepě nestačí.
Laicky řečeno: dobře napsaná aplikace se ke každému vstupu chová jako ostraha na vstupu — zkontroluje ho, než ho pustí dovnitř. Většina těchto chyb vzniká tam, kde tahle kontrola chybí.
6. Monitoring a logování
Nestačí útokům jen předcházet — potřebujete také vědět, když se něco děje. Monitoring sleduje dostupnost a chování aplikace a upozorní vás, když začne padat, neúměrně se zpomalí nebo někdo zkouší tisíce přihlášení za minutu. Logy (záznamy o událostech) zase umožní zpětně zjistit, co se stalo, kdy a odkud.
Bez monitoringu se o problému často dozvíte až od naštvaného zákazníka, nebo dokonce z Googlu, který váš web označí za napadený. S nastaveným sledováním dostanete upozornění dřív, než si výpadku všimnou uživatelé. Proto by měl být průběžný dohled běžnou součástí správy aplikace, ne něčím, co řešíte až po incidentu.
7. Penetrační testy a bezpečnostní audit
Penetrační test je řízený pokus o průnik do aplikace — bezpečnostní specialista se vžije do role útočníka a snaží se najít slabá místa dřív, než je objeví někdo se špatným úmyslem. Výstupem je srozumitelná zpráva: co je zranitelné, jak vážné to je a jak to opravit. Je to rozdíl mezi „myslíme si, že jsme v bezpečí“ a „ověřili jsme si to“.
Takový test dává smysl zejména před spuštěním nové aplikace, po větších změnách nebo pravidelně u systémů, které pracují s citlivými či platebními daty. U menších projektů často postačí lehčí bezpečnostní audit a kontrola konfigurace. Důležité je, aby na konci nezůstala jen zpráva v šuplíku — nálezy se musí skutečně opravit a zkontrolovat.
8. Ochrana osobních dat a GDPR
Pokud vaše aplikace zpracovává údaje o lidech — a to dělá skoro každý web s kontaktním formulářem nebo zákaznickým účtem — vstupuje do hry GDPR. Bezpečnost a ochrana osobních dat spolu úzce souvisí: GDPR po vás chce, abyste osobní údaje chránili „odpovídajícími technickými opatřeními“, což jsou přesně věci z tohoto článku — šifrování, řízení přístupů, zálohy, kontrola toho, kdo k datům smí.
- Sbírejte jen údaje, které opravdu potřebujete — co nemáte, to nemůžete ztratit.
- Mějte přehled, kde všude se data nacházejí (databáze, e-maily, zálohy, externí služby).
- Ošetřete předávání dat dalším nástrojům a zpracovatelům smluvně i technicky.
- Mějte připravený postup pro případ úniku — únik osobních dat se za určitých podmínek hlásí úřadu do 72 hodin.
GDPR není jen o právních dokumentech, ale hlavně o tom, že s daty zacházíte zodpovědně. Dobře zabezpečená aplikace vám plnění těchto povinností výrazně usnadní.
Jak na to v praxi
Bezpečnost není jednorázový úkol, který odškrtnete a zapomenete. Je to průběžná disciplína — aplikace se vyvíjí, přibývají funkce, mění se prostředí i útočníci. Nejlepší výsledky vidíme tam, kde se na bezpečnost myslí už při návrhu a kde má někdo jasně na starost údržbu, aktualizace a dohled. Nemusíte tomu rozumět do detailu vy; potřebujete ale partnera, který se na to dívá systematicky a umí vám srozumitelně říct, kde stojíte.
Praktický první krok: projděte si těchto osm bodů jako kontrolní seznam u vlastní aplikace. I jednoduché „máme to / nemáme / nevíme“ u každého bodu vám rychle ukáže, kde máte největší slabiny.
Bezpečnost webových aplikací se nedá vyřešit jedním nákupem ani jednou kontrolou — je to průběžná péče, která chrání vaše data, zákazníky i pověst. Pokud si nejste jistí, jak na tom vaše aplikace je, projděte si nálezy s někým, kdo se na to dívá denně. V Quantivě umíme provést bezpečnostní audit, nastavit aktualizace, zálohy a monitoring i převzít dlouhodobou správu vaší aplikace. Ozvěte se nám přes nezávaznou konzultaci a společně zjistíme, kde máte největší slabiny a co řešit jako první.
