Postavit aplikaci dnes umí skoro každý. Postavit ji bezpečně už je jiná liga, a právě tady se odděluje hračka od nástroje, kterému lidé svěří svoje data. Projdu osm věcí, které musíš ohlídat, i když nejsi programátor. Žádný žargon, jen co reálně rozhoduje o tom, jestli o data přijdeš, nebo ne.
1. Hesla nikdy neukládej v čitelné podobě
Tohle je úplný základ, a přesto na něm padá překvapivě dost projektů. Heslo uživatele se nikdy neukládá tak, jak ho napsal. Ukládá se jeho otisk (hash) spočítaný pomocí algoritmu jako bcrypt nebo argon2id. I kdyby ti někdo ukradl celou databázi, hesla z otisku nezíská.
Co nesmíš nikdy použít: ukládání hesla jako prostého textu, ani staré algoritmy MD5 a SHA-1. Ty jsou dnes prolomené během sekund.
2. Všechno žene přes HTTPS
HTTPS šifruje komunikaci mezi prohlížečem a serverem. Bez něj může kdokoliv na stejné wifi odposlechnout, co uživatelé posílají, včetně hesel. Dnes je HTTPS zdarma a u většiny hostingů zapnuté automaticky, takže tady není výmluva. Pozná se podle zámečku v adresním řádku a předpony https.
3. Hlídej, kdo vidí čí data
Nejčastější tichý únik dat nevzniká útokem zvenčí, ale chybou v aplikaci, kde uživatel A omylem vidí data uživatele B. Stačí, že někde chybí kontrola, komu záznam patří. V databázi se to řeší pravidly přístupu na úrovni řádků (row level security). Detailně to vysvětluji v článku row level security vysvětleno.
4. Nevěř ničemu, co přijde od uživatele
Každý vstup z formuláře, z URL nebo z API ber jako potenciálně nepřátelský, dokud ho neověříš. Útočník tam totiž může poslat cokoliv. Co je potřeba dělat:
- Validovat každý vstup: je to opravdu e-mail? Je číslo v rozumném rozsahu?
- Sanitizovat texty, které se zobrazí ostatním, aby nešlo do stránky propašovat cizí skript.
- Filtrovat citlivá pole jako role nebo id vlastníka, aby je nešlo přepsat zvenčí.
5. Tajné klíče patří mimo kód
API klíče, hesla k databázi a tokeny nikdy nepatří přímo do kódu ani do gitu. Jednou jsem viděl projekt, kde klíč ležel ve veřejném repozitáři, a do hodiny ho někdo zneužil. Tajemství patří do proměnných prostředí (environment variables), které jsou oddělené od kódu a nikdy se nezveřejní.
6. Omez počet pokusů
Pokud útočník může zkoušet hesla tisíckrát za minutu, dřív nebo později uhodne. Rate limiting omezí, kolikrát za daný čas může jeden uživatel zkusit přihlášení nebo jinou citlivou akci. Po pár neúspěšných pokusech se další na chvíli zablokují. Jednoduché opatření, které zastaví celou kategorii útoků hrubou silou.
Stejnou logiku nasaď i na drahé operace, jako je odesílání e-mailů nebo volání placeného API. Bez limitu ti někdo může z aplikace udělat nástroj na rozesílání spamu nebo ti během noci protočí účet za AI o tisíce korun. Limit na akci a na uživatele je levná pojistka proti dražším problémům.
7. Zálohuj a otestuj obnovu
Bezpečnost není jen o útočnících. Stačí špatně napsaný příkaz a smažeš si data sám. Pravidelná automatická záloha je povinnost. Stejně důležité je obnovu aspoň jednou vyzkoušet, protože záloha, ze které neumíš obnovit, je k ničemu. Ověř, za jak dlouho jsi schopný appku po výpadku rozjet.
8. Aktualizuj knihovny
Tvoje aplikace stojí na desítkách cizích knihoven. V některé z nich se časem najde díra a vyjde oprava. Pokud knihovny neaktualizuješ, jedeš na verzi s veřejně známou zranitelností, ke které existuje návod, jak ji zneužít. Stačí pravidelně pouštět kontrolu závislostí a opravy nasazovat. U běžných projektů na to existují automatické nástroje, které ti samy otevřou návrh na aktualizaci.
Bonus: nelogguj, co nemáš
Při hledání chyb se hodí logy, ale je snadné do nich omylem zapsat heslo, token nebo celou platební kartu. Logy se pak válejí na serveru i u třetích stran a stávají se z nich tikající bomby. Pravidlo je jednoduché: do logů nikdy nepiš hesla, klíče ani citlivé osobní údaje. Když potřebuješ logovat požadavek, citlivá pole z něj nejdřív vyhoď.
Rychlý přehled, co kontrolovat
| Oblast | Co ohlídat | Riziko při zanedbání |
|---|---|---|
| Hesla | Hashování bcrypt/argon2 | Únik všech hesel |
| Přenos | HTTPS všude | Odposlech komunikace |
| Přístup | Kontrola vlastníka dat | Cizí lidé vidí cizí data |
| Vstupy | Validace a sanitizace | Vložení škodlivého kódu |
| Tajemství | Klíče mimo kód | Zneužití přístupů |
Časté dotazy
Musím tohle všechno řešit i u malé aplikace?
Ano, alespoň body o heslech, HTTPS, přístupu k datům a klíčích. Útočníci nerozlišují velikost projektu, automaticky skenují internet a zkoušejí každého. Malá aplikace s reálnými daty je stejně lákavý cíl.
Co je GDPR a týká se mě?
Pokud zpracováváš osobní údaje lidí z EU, ano. V praxi to znamená vědět, jaká data sbíráš, proč, jak dlouho je držíš a umět je na žádost smazat. Bezpečné uložení dat je nutný základ, na kterém GDPR teprve stojí.
Jak poznám, že je moje aplikace bezpečná?
Stoprocentní jistotu nemáš nikdy, ale dobrým krokem je bezpečnostní audit: někdo zkušený projde kód a nastavení a hledá slabiny dřív, než je najde útočník. Vyplatí se to zvlášť před spuštěním nebo když začneš zpracovávat citlivější data.
Stačí mi pro hesla přihlášení přes Google?
Přihlášení přes Google nebo Apple je dobrá volba, protože hesla pak vůbec neřešíš ty, ale velký poskytovatel s celými týmy na bezpečnost. Pokud ale chceš i vlastní e-mail a heslo, platí pro ně všechna pravidla z bodu jedna. Obě cesty se dají kombinovat.
Když si nejsi jistý
Bezpečnost je oblast, kde se chyby platí draho a často pozdě. Pokud stavíš aplikaci, do které lidé zadají svoje data, vyplatí se nechat si zabezpečení zkontrolovat. Dělám audity i návrh bezpečných aplikací na míru a umím srozumitelně vysvětlit, kde jsi zranitelný a co s tím. Napiš mi přes kontakt a projdeme to společně.