API a bezpečnost: jak ochránit koncové body bez firewallu

4. února 2026

•

Rozhraní API se stalo páteří moderních webů, aplikací i digitálních služeb. Právě proto je také jedním z nejčastějších cílů útoků. Zatímco klasické weby chráníme pomocí firewallů a WAF řešení, u API tento přístup často selhává nebo vůbec nedává smysl. Jak tedy zabezpečit API koncové body, když nemáte (nebo nechcete mít) tradiční firewall?

Proč firewall u API často nestačí

Tradiční firewall nebo WAF byl navržen především pro ochranu klasických webových stránek, nikoli moderních API rozhraní (umožňuje společnou komunikaci různých aplikací a služeb). U API proto řeší jen malou část reálných hrozeb, a někdy dokonce vytváří falešný pocit bezpečí, uvádí web Owasp.

Hlavní důvody, proč firewall API neochrání dostatečně:

API pracuje s daty, ne s HTML – firewall kontroluje strukturu požadavků, ale API útoky jsou často logické. Validní JSON může vracet cizí nebo příliš mnoho dat a firewall to nepozná.
Největší hrozby jsou logické chyby – chybná autorizace, přístup k cizím objektům nebo nadměrné vystavení dat patří mezi nejčastější problémy.
Firewall neřeší oprávnění – ověří existenci tokenu, ale neví, co konkrétní uživatel smí dělat s konkrétními daty.
Automatizovaný provoz splývá s útokem – API běžně obsluhuje aplikace a služby, takže vysoký počet požadavků není nutně podezřelý.
Zneužití dat zůstává skryté – postupné stahování dat nebo postupné procházení ID objektů firewall nerozpozná.

Podle webu Cloudflare firewall může API doplnit, ale neochrání ho sám. Klíčová bezpečnost API musí být řešena přímo v aplikaci – přes autentizaci, autorizaci a kontrolu přístupů.

Jak ochránit koncové body bez firewallu

1. Autentizace (žádné API bez identity)

Základní pravidlo bezpečného API zní jednoduše – každý požadavek musí být jednoznačně identifikovatelný. API, které přijímá anonymní žádosti, nemá žádnou kontrolu nad tím, kdo ho používá. A tím pádem ani nad tím, jak a k čemu je zneužíváno.

Bez autentizace nelze omezovat přístup k citlivým datům, rozlišovat role a oprávnění, efektivně logovat a vyhodnocovat incidenty nebo nastavit smysluplné limity provozu.

Nejčastější způsoby autentizace API:

API klíče – jednoduché řešení vhodné pro interní nebo méně citlivá rozhraní. Slouží k identifikaci aplikace, ne uživatele. Pokud klíč unikne, útočník získá stejná práva jako legitimní klient.
Tokeny (např. JWT) – token nese informaci o identitě i oprávněních volajícího. API si může ověřit jeho platnost bez dotazu na databázi, což zvyšuje výkon i škálovatelnost. Nutností je omezená platnost a kontrola podpisu.
OAuth 2.0/OpenID Connect – standardní přístup pro mobilní aplikace, externí integrace a scénáře, kdy API využívají třetí strany. Umožňuje bezpečné delegování přístupu bez sdílení hesel.

2. Autorizace

Autentizace odpovídá na otázku, kdo volá. Autorizace řeší mnohem důležitější část – co přesně smí dělat. Právě zde vzniká největší množství kritických chyb v API, a to i u technicky dobře navržených aplikací.

Typický omyl vypadá takto: uživatel je přihlášený → má přístup ke koncovému bodu → systém dál nic neřeší. Výsledkem je API, které funguje správně, ale dovoluje přístup k cizím datům.

Nejčastější chyby v autorizaci API:

Přístup k objektům pouze podle ID – koncový bod vrací data podle identifikátoru v URL, ale nekontroluje, zda daný objekt patří volajícímu. Útočník pak jen mění ID a čte cizí záznamy.
Chybějící kontrola rolí – API nerozlišuje běžného uživatele, administrátora nebo systémovou službu. Výsledkem je přístup k funkcím, které měly zůstat interní.
Autorizace jen na úrovni koncového bodu – kontrola typu „máš přístup k /orders“ sama o sobě nestačí. API musí vždy ověřit, zda má volající oprávnění pracovat s konkrétní objednávkou, položkou nebo záznamem, nikoli jen s koncovým bodem jako takovým.
Implicitní důvěra v klienta – backend předpokládá, že frontend pošle správná data. API ale musí počítat s tím, že žádost může poslat kdokoli, a to včetně útočníka.

API musí kontrolovat oprávnění u každého požadavku a ke každému objektu. Nestačí vědět, kdo volá. Klíčové je ověřit, zda má právo pracovat s konkrétními daty. Bez toho je i jinak zabezpečené API otevřené zneužití.

3. Rate limiting (ochrana proti zneužití i chybám)

Rate limiting určuje, kolik požadavků může klient nebo uživatel odeslat za určitý časový úsek. U API nejde jen o obranu proti útokům, ale také o ochranu samotného systému před chybami a nečekaným chováním legitimních klientů.

Bez rate limitingu může jediný koncový bod zahltit databázi, způsobit výpadek služby nebo otevřít cestu k masovému sběru dat.

Proč je rate limiting pro API klíčový:

Ochrana proti brute-force útokům – omezení počtu žádostí znemožňuje systematické hádání tokenů, ID objektů nebo dalších citlivých parametrů.
Prevence hromadného stahování dat – i veřejné API může být zneužito k postupnému vysátí databáze. Rate limiting výrazně zpomaluje nebo zcela zastaví tento typ zneužití.
Ochrana proti chybám u klientů – špatně napsaná mobilní aplikace nebo integrace může generovat tisíce požadavků za sekundu. Limity zabrání tomu, aby jedna chyba položila celý backend.
Stabilita a férové sdílení zdrojů – limity zajistí, že jeden klient nevyčerpá kapacitu na úkor ostatních.

Rate limiting je nejlepší nastavovat kombinovaně. Základ tvoří omezení podle IP adresy, přesnější kontrolu pak umožňují limity podle API klíče nebo tokenu. U náročných či citlivých operací je vhodné nastavit limity přímo na úrovni konkrétních koncových bodů.

V praxi se osvědčuje spojení krátkodobých limitů (ochrana proti nárazům) a dlouhodobých limitů (prevence systematického zneužití).

4. Validace vstupů

U API je lákavé věřit, že když žádost posílá náš web nebo mobilní aplikace, bude v pořádku. Jenže útočník nemusí hacknout klienta. Stačí mu poslat žádost přímo (Postman, curl, vlastní skript). Proto platí pravidlo – API musí validovat každý vstup, i kdyby přicházel z vašeho vlastního frontendu.

Bez důsledné validace vznikají tři typické problémy – bezpečnostní díry, nekonzistentní data v databázi a chyby, které se špatně ladí.

Co všechno by měla validace řešit:

Typy a formát dat – číslo není řetězec a datum není libovolný text. Validujte formát e-mailu, telefonů, UUID, timestampů (časová razítka) apod.
Rozsahy a limity – hlídání min/max hodnot (např. množství, cena, stránkování) a délky řetězců. Je to ochrana proti chybám i proti pokusům o přetížení.
Povinná a zakázaná pole – kontrolujte, že žádost pole opravdu existují, a zároveň odmítejte pole, která API neočekává (jinak si útočník propašuje něco navíc).
Whitelist místo blacklistu – nesnažte se vyjmenovat, co zakázat, ale jasně definujte, co je povoleno. Tento přístup je bezpečnější a výrazně hůře se obchází.
Validace v každém koncovém bodu – nespoléhejte na to, že „už to kontroluje klient“ nebo že „to přece chodí z jedné aplikace“. Každý koncový bod si musí hlídat vlastní vstup.

Nejrychlejší a nejčistší cestou k důsledné validaci je opřít se o schéma API. Pomocí OpenAPI (Swagger) vzniká jasný kontrakt, který přesně definuje, jak mají žádosti a odpovědi vypadat.

Schéma lze využít přímo v runtime k automatické validaci vstupů i výstupů, včetně odmítání neznámých polí a nesprávných datových typů. Výsledkem je, že se z validace stává systémové pravidlo, nikoli sada ručně psaných podmínek rozházených po kódu.

5. Oddělení veřejného a interního API

Jedna z nejčastějších příčin průšvihů u API není špatná kryptografie, ale prostý fakt, že interní rozhraní omylem vidí celý internet.

Veřejné API má být navržené tak, aby přežilo cizí klienty, pokusy o zneužití i agresivní provoz. Interní API (pro admin, microservisy, integrace) naopak často vzniká pro naše lidi. A pokud se dostane ven, bývá to zkratka k incidentu.

Proč je oddělení tak důležité:

Jiná úroveň rizika a očekávání – veřejné API musí počítat s útoky a neznámými klienty. Interní API typicky ne, a proto bývá méně přísné (větší oprávnění, méně limitů, praktické koncové body).
Interní endpointy bývají silnější než veřejné – administrátorské akce, exporty, hromadné operace, ladění koncových bodů, health-checky s detaily (přesně ty věci, které útočník chce).
„Security by obscurity“ (bezpečnost díky nejasnosti) nefunguje – spoléhat na to, že URL nikdo nezná, je slabá obrana. Koncové body se dají prohledat, uhodnout, nebo uniknou v klientském kódu, logách či dokumentaci.

Jak to udělat prakticky:

1) API rozdělte na veřejnou a interní část – ideálně na samostatné domény (api.example.com a internal-api.example.com), případně alespoň na oddělené cesty.

2) Interní API zpřístupněte výhradně z privátní sítě (VLAN/VPC, VPN nebo Zero Trust přístup), aby nebylo dostupné z internetu.

3) Administrátorské koncové body chraňte samostatnou autentizací (SSO, MFA), přísnějšími limity a auditními logy.

4) V produkci zakažte debug (ladění) a testovací koncové body, důsledně oddělte oprávnění – tokeny pro public API nesmí fungovat pro interní služby, které mají mít vlastní identity a minimální rozsah.

6. Logování a monitoring místo firewallu

Pokud API nechrání klasický firewall, musí ho chránit viditelnost. U API totiž útoky často nevedou k chybám ani výpadkům. Probíhají tiše, dlouhodobě a vypadají jako legitimní provoz. Právě proto je logování a monitoring klíčovou bezpečnostní vrstvou, nikoli jen provozním doplňkem.

Bez kvalitních logů nevíte, kdo API používá, k jakým datům přistupuje a zda nedochází ke zneužití oprávnění.

Co by měl monitoring API sledovat:

Autentizační a autorizační chyby – opakované chyby 401 a 403 často signalizují pokusy o hádání tokenů, testování oprávnění nebo postupné procházení objektů.
Neobvyklé vzorce chování – náhlý nárůst žádostí, sekvenční změny ID v URL nebo systematické procházení koncových bodů jsou typickým znakem zneužití API.
Objem a typy volání – sledujte, kdo a jak často volá citlivé koncové body (exporty, hromadné operace, admin funkce).
Chybové stavy aplikace – opakované chyby 4xx a 5xx mohou znamenat útok, špatně napsaného klienta nebo regresi po nasazení.

U klasického webu se problém většinou rychle projeví. Uživatelé si stěžují nebo je chyba viditelná. U API je situace jiná. Útočník mlčí, data odtékají postupně a incident se často odhalí až se zpožděním. Právě proto je monitoring u API zásadní.

Pouhé hromadění logů nestačí. Logování má hodnotu jen tehdy, když z něj lze vyčíst, kdo API volá, co dělá a s jakými daty pracuje. Důležité jsou také aktivní výstrahy a pravidelné vyhodnocování. Jedině tak se monitoring stává funkční náhradou firewallu a nástrojem včasného odhalení problémů.

API se nechrání zdí, ale pravidly

Bezpečnost API dnes nestojí na jednom centrálním firewallu, ale na kombinaci správné autentizace, autorizace, omezení provozu a kontroly dat. Útočníci už dávno nehledají díry ve formulářích. Hledají logické chyby v rozhraních, která propojují celý systém.