Bezpečnost API: autentizace, limity a ochrana dat
Platný token ještě neznamená oprávnění ke každému záznamu. Bezpečné API musí při požadavku ověřit identitu, povolenou akci, konkrétní data i přijatelné náklady. K tomu potřebuje pravidla pro klíče, logy a změny. Tento průvodce ukazuje, co požadovat při návrhu a jak výsledek ověřit na modelovém firemním rozhraní.
API je dohoda, jak spolu systémy komunikují. Může číst faktury, měnit objednávky nebo spouštět placenou službu. Chyba proto nemusí znamenat jen nedostupnou stránku: může zpřístupnit údaje jiné firmy nebo vytvořit náklad, kterého si tým všimne až na vyúčtování. Samotné HTTPS ani přihlašovací obrazovka všechny tyto situace neřeší.
Obecný postup propojení popisuje průvodce API integracemi. Zde se zaměříme na hranice přístupu a provozu u vlastního API, včetně systému pro více zákaznických organizací. Příklady jsou ilustrativní, nikoli výsledky klientského auditu. Primární podklady OWASP a IETF jsme ověřili 28. října 2026.
01Sepište rozhraní, data a odpovědnost
Začněte seznamem skutečně dostupných rozhraní. OWASP upozorňuje na riziko neúplného inventáře, zejména zapomenutých verzí a testovacích prostředí. U každé části určete vlastníka, účel, klienty, typ dat a plán ukončení podpory. Dokumentace nové verze neznamená, že stará adresa přestala odpovídat.
Do přehledu patří i exporty, administrace, webhooky, dávkové importy a úlohy na pozadí. Sepište, kdo údaje poskytuje, kdo je dostává a kdy vzniká placená operace. U externího dodavatele rozlišujte odpovědnost za jeho službu a za vaše použití. Klíč s nadměrnými právy je vaše riziko i tehdy, když dodavatel funguje správně.
Výstupem má být krátká mapa a sada rozhodnutí, ne pouze seznam URL. Kdo smí obnovit přístup? Kdo schvaluje nový export? Kdo zastaví problémovou integraci? Bez těchto odpovědí se technická ochrana obtížně provozuje. Nejdřív řešte rozhraní, která mohou zpřístupnit cizí data nebo provést významnou změnu.
02Autentizace a autorizace odpovídají na jiné otázky
Autentizace ověřuje předloženou identitu nebo přihlašovací prostředek. Autorizace rozhoduje, co daný subjekt smí udělat. OWASP doporučuje minimální oprávnění, výchozí zamítnutí a kontrolu každého požadavku. Přihlášený účet proto nemá automaticky nárok na všechny faktury ani na každou administrativní funkci.
| Kontrola | Otázka | Příklad rozhodnutí |
|---|---|---|
| Autentizace | Komu nebo čemu patří ověřený přístup? | Token náleží konkrétnímu klientovi a uživateli, pokud je zastupuje. |
| Funkce | Smí tento subjekt provést akci? | Čtenář nesmí schválit platbu. |
| Objekt | Smí pracovat právě s tímto záznamem? | Faktura patří dostupné organizaci a oprávněnému rozsahu. |
| Vlastnosti | Která pole smí číst nebo měnit? | Běžná aktualizace profilu nemůže přidělit správce. |
Rozhodnutí patří na server. Skryté tlačítko nebo filtr ve frontendové aplikaci pouze upravuje uživatelské rozhraní. Stejnou operaci může zavolat jiný klient. Přístupová pravidla formulujte jazykem domény: například účetní smí číst faktury přiřazených poboček, ale nesmí měnit bankovní účet dodavatele. To je přesnější než neurčité „uživatel má přístup do systému“.
03Zvolte přihlašovací mechanismus podle typu klienta
Rozlišujte člověka používajícího aplikaci a službu komunikující se službou. OAuth 2.0 řeší delegovaný přístup; OpenID Connect nad ním přidává ověření identity uživatele. Pro autorizační tok s kódem vycházejte z RFC 9700, včetně PKCE pro veřejné klienty. Nevytvářejte vlastní přihlašovací protokol jen kvůli kratší implementaci.
API klíč může identifikovat integraci, ale sám nemusí určit konkrétního člověka, jeho roli ani organizaci. Každé integraci přidělte samostatný přístup a potřebný rozsah. Tajný klíč vložený do veřejného JavaScriptu nebo distribuované mobilní aplikace nelze považovat za důvěrné serverové tajemství. Architektura musí počítat s tím, kde se klient skutečně spouští.
JWT je formát tokenu, nikoli kompletní bezpečnostní řešení. Podle doporučení IETF pro JWT ověřujte kryptografii, důvěryhodného vydavatele a zamýšleného příjemce; kontrolujte také časovou platnost podle použitého profilu. Podepsaný token není automaticky šifrovaný. ID token pro přihlášení nezaměňujte za přístupový token pro API.
04Každý záznam musí projít kontrolou oprávnění
Broken Object Level Authorization označuje chybějící nebo nesprávnou kontrolu přístupu ke konkrétním objektům. Změna číselného ID na UUID tento problém sama neopraví. Server musí rozhodnout, zda ověřený subjekt smí s požadovaným záznamem pracovat, a to při čtení, změně, mazání i exportu.
Modelový systém vede faktury firem A a B. Účetní firmy A smí číst vybrané faktury A. Test se správným tokenem a fakturou A tedy může uspět. Stejný účet s identifikátorem faktury B musí být odmítnut bez zpřístupnění jejího obsahu. Je to očekávaný výsledek testu, nikoli tvrzení, že jsme takovou chybu na skutečném webu našli.
Do pravidla může vstupovat i pobočka, přidělení zakázky nebo stav dokumentu. Přístup pouze podle shodného ID uživatele proto nemusí stačit. Stejnou politiku použijte u detailu, seznamu, vyhledávání i dávkové akce. Pokud detail chráníte, ale export vybere všechny řádky, hranice přístupu zůstala otevřená.
05Oddělte organizace také v cache a úlohách na pozadí
V systému pro více zákazníků znamená tenant samostatnou zákaznickou organizaci. OWASP popisuje izolaci tenantů napříč daty, cache i zpracováním. Identifikátor organizace z požadavku není sám důkazem členství. Ověřte vazbu na přihlášený subjekt a bezpečně přeneste tento kontext do navazujících operací.
Cache faktury musí rozlišit všechny okolnosti, které mění obsah nebo oprávnění, například organizaci a uživatelský rozsah. Oddělený klíč cache přitom nenahrazuje autorizaci. Stejně důležitá je fronta: úloha vytvořená pro firmu A se nesmí při zpracování provést v kontextu firmy B. Kontrolujte také soubory, vyhledávací index a odkazy ke stažení.
Určete, co se stane při odebrání členství nebo změně role během čekání úlohy. Pro citlivou operaci může být potřebné znovu ověřit aktuální oprávnění při spuštění a při stažení výsledku. Samostatná databáze může posílit izolaci, ale neopraví chybnou volbu zákazníka v aplikaci. Každá vrstva potřebuje odpovídající důkaz.
06Povolujte konkrétní pole a obchodní operace
OWASP rozlišuje i oprávnění na úrovni vlastností objektu. API nemá automaticky vracet celý databázový záznam ani ukládat každé pole přijatého objektu. Pro jednotlivé operace určete povolená vstupní a výstupní pole. Technicky platný JSON může obsahovat změnu, kterou daný uživatel provést nesmí.
U modelového profilu lze povolit jméno a telefon, zatímco role správce a schválení účtu mají vlastní řízený postup. U faktury může zákazník vidět částku a splatnost, ale nemusí mít přístup k interní poznámce. Odstranění pole až ve frontendovém zobrazení data nechrání: pokud je server odeslal, klient je již získal.
Ověřujte také stav procesu. Oprávnění vytvořit návrh nemusí znamenat oprávnění jej schválit a zaplacený doklad nemusí dovolovat stejnou změnu jako koncept. Pravidla musí přežít jinou HTTP metodu, dávkové rozhraní i novou verzi API. Důležité přechody řešte explicitně a atomicky podle potřeb domény.
07Limity provozu a kvóty mají odlišný účel
V návrhu rozlišujte rychlost požadavků, souběžnou práci a celkovou spotřebu. Rate limit obvykle chrání tempo v určeném časovém okně. Kvóta zde znamená přidělený objem za delší období nebo rozpočet. Názvosloví dodavatelů se liší, proto popište konkrétní pravidlo, jednotku, vlastníka a chování po vyčerpání.
| Ochrana | Co omezuje | Co ověřit |
|---|---|---|
| Rate limit | Tempo požadavků pro klienta, účet nebo operaci. | Krátká špička a běžný provoz mají předvídatelný výsledek. |
| Kvóta | Celkový objem nebo rozpočet zákazníka za období. | Více klíčů jedné firmy neobejde společnou kvótu. |
| Souběh | Počet současně běžících náročných úloh. | Další export nezablokuje interaktivní požadavky. |
| Velikost a náročnost | Tělo požadavku, počet položek nebo rozsah výpočtu. | Jediný přijatý požadavek nemůže spustit neomezenou práci. |
Pro příliš mnoho požadavků definuje RFC 6585 stav 429; odpověď může uvést Retry-After. Klient potřebuje omezené opakování s prodlevou, aby problém nezhoršoval. Limit jen podle IP může spojit různé zákazníky za jednou sítí. U distribuovaného API ověřte, že součet limitů na jednotlivých instancích neumožní překročit zamýšlenou společnou hranici.
08Chraňte také náklady jednoho požadavku
OWASP API4 zahrnuje nejen CPU a paměť, ale také placené externí operace. Jeden požadavek může rozeslat mnoho zpráv nebo vytvořit rozsáhlý export. Omezení počtu volání proto doplňte limitem položek, časem zpracování, stránkováním a kontrolou počtu navazujících úkonů. Drahé operace mají mít vlastní pravidla.
Před spuštěním placené práce rezervujte odpovídající kapacitu nebo rozpočet způsobem, který obstojí při souběhu. Pouhé přečtení zůstatku a pozdější odečtení může několika požadavkům dovolit spotřebovat stejnou rezervu. U neúspěchu určete, co se uvolní a co již skutečně vzniklo. Zákazník má poznat rozdíl mezi čekáním, odmítnutím a dokončením.
Limity ověřujte společně s výkonem databáze a API. Timeout u klienta nezaručuje ukončení práce na serveru. Sledujte i fronty a návazné služby. Idempotentní zpracování pomůže omezit duplicitní účinky opakování, ale klíč idempotence musí mít správný rozsah klienta a operace a nenahrazuje kontrolu oprávnění.
09Klíče potřebují vlastníka a celý životní cyklus
OWASP Secrets Management rozlišuje vytvoření, rotaci, odvolání a expiraci tajemství. U každého přístupu evidujte účel, vlastníka, oprávnění a prostředí. Produkce a test nemají sdílet jeden klíč. Tajemství poskytujte aplikaci řízenou cestou a neposílejte je do dokumentace, repozitáře nebo běžných logů.
Při plánované rotaci může pomoci krátké řízené překrytí starého a nového klíče. Potvrďte přechod všech klientů a starý přístup odvolejte. Při podezření na únik má přednost omezení zneužití; neponechávejte kompromitovaný klíč aktivní jen kvůli pohodlí migrace. Připravte postup tak, aby výměna nevyžadovala improvizaci během incidentu.
Krátká platnost tokenu omezuje časové okno, ale nemusí znamenat okamžité odvolání. Předem rozhodněte, jak zastavíte již vydané přístupy a jak rychle se změna projeví ve všech službách. Řešení závisí na typu tokenu a infrastruktuře. Pouhé vytvoření nového tajemství nestačí, pokud staré zůstává přijímané.
10Validujte vstupy, výstupy a externí události
OWASP REST Security doporučuje HTTPS, kontrolu vstupů a bezpečné zacházení s citlivými údaji. Ověřujte typy, rozsahy, povolené metody i velikost vstupu. CORS je pravidlo pro prohlížeče, nikoli autorizace serverového klienta. U autentizace přes cookies řešte odpovídající ochranu proti CSRF. Konfiguraci vybírejte podle konkrétního toku.
Webhook musí ověřit původ i zpracování události. Například Stripe dokumentuje podpisy, opakování a duplicitní události. Použijte doporučené ověření dodavatele nad správnými daty, kontrolu časového kontextu a ochranu před opakovaným účinkem. Ověřený podpis není důkaz, že událost patří správnému zákazníkovi nebo smí změnit libovolnou objednávku.
Pokud API stahuje soubor z adresy dodané klientem, posuďte riziko SSRF. Omezte dostupné cíle a odchozí komunikaci, včetně přesměrování a interních služeb. Také odpověď důvěryhodného partnera je vstup, který potřebuje validaci a rozumné limity. Integrace nemá automaticky získat důvěru ke všemu, co vrátí.
11Logy mají vysvětlit událost bez dalšího úniku
OWASP Logging doporučuje zaznamenávat bezpečnostně významné události a chránit samotné záznamy. Pro provozní šetření obvykle potřebujete čas, identifikátor požadavku, subjekt, organizaci, operaci a výsledek. Nepřidávejte celé tokeny, hesla ani kompletní těla požadavků jen proto, že se snadno zapisují. Citlivý obsah omezte podle skutečné potřeby.
Sledujte například opakovaná zamítnutí přístupu mezi organizacemi, neobvyklé exporty a náhlý růst placených operací. Samotný počet chyb nemusí odlišit útok od vadného klienta, proto přidejte kontext a odpovědnost za vyhodnocení. Alarm bez příjemce a postupu řešení je pouze další zpráva. Otestujte i situaci, kdy přestane fungovat sběr logů.
Incidentní postup má umět omezit dotčený přístup, zachovat podklady a určit rozsah dopadu. Zastavení celého API nemusí být první volba, pokud lze bezpečně vypnout konkrétní integraci. Současně neslibujte zachování provozu za každou cenu. O případných oznamovacích povinnostech rozhodujte podle skutečné události a relevantních pravidel.
12Přebírejte ověřené scénáře, ne seznam technologií
Před předáním připravte testovací účty se skutečně odlišnými rolemi a organizacemi a neprodukční data. U každého scénáře určete očekávaný výsledek, prostředí a důkaz. Nejde jen o to, že správný uživatel uspěje. Potřebujete prokázat i zamítnutí nepovolené operace bez vedlejšího účinku a bez úniku citlivých údajů.
- Účet firmy A nezíská detail, seznam ani export neveřejných dat firmy B.
- Role pro čtení nemůže zapisovat a běžná změna profilu nemůže přidělit správce.
- Neplatný, expirovaný nebo odvolaný přístup selže podle stanovené politiky.
- Omezení obstojí při souběhu, více klíčích i více instancích služby.
- Duplicitní událost neprovede tutéž obchodní změnu znovu.
- Logy pomohou dohledat rozhodnutí a neobsahují přístupová tajemství.
- Po změně role, nové verzi nebo úpravě exportu se příslušné testy zopakují.
Výsledek spojte s konkrétní opravou a následným ověřením. Bezpečnostní audit API může prověřit důležité hranice, ale provozní vlastnictví zůstává průběžnou prací týmu. Do zadání zahrňte rozsah, testované role, omezení kontroly a plán oprav. Nákup brány nebo knihovny není sám o sobě přejímacím důkazem.
13Časté otázky
Stačí API chránit pomocí HTTPS?
HTTPS chrání komunikaci při přenosu. Nerozhoduje, zda ověřený účet smí číst konkrétní fakturu nebo měnit dané pole. Potřebujete také autorizaci, vhodné limity, kontrolu vstupů a správu přístupů. Jednotlivé vrstvy řeší odlišné situace.
Je JWT bezpečnější než neprůhledný token?
Samotný formát bezpečnost neurčuje. Záleží na ověřování, uložení, rozsahu oprávnění, době platnosti a možnosti odvolání. JWT může nést čitelné údaje a jeho podpis neznamená šifrování. Vyberte řešení podle architektury a provozních požadavků.
Ochrání UUID před přístupem k cizím datům?
Hůře odhadnutelný identifikátor může ztížit některé pokusy, ale nenahrazuje oprávnění. ID se může objevit v odkazu, logu nebo odpovědi. Server musí odmítnout nepovolený přístup i tehdy, když klient správný identifikátor zná.
Jaký rate limit máme nastavit?
Univerzální číslo neexistuje. Rozlišujte běžné čtení, export a placenou operaci. Vyjděte z měření kapacity, obvyklého používání a přijatelného nákladu. Uveďte jednotku, časové okno, subjekt a chování klienta po překročení. Hranici ověřte při souběhu.
Můžeme dát všem integracím jeden společný klíč?
Oddělené přístupy usnadní minimální oprávnění, dohledání původu a odvolání jediné integrace. Společný klíč tyto možnosti omezuje a jeho výměna zasáhne více klientů. Každý přístup má mít vlastníka, účel a známý postup ukončení.
Vyřeší bezpečnost API gateway?
Brána může ověřovat tokeny, filtrovat požadavky a řídit některé limity. Obvykle však sama nezná všechna pravidla konkrétní faktury, organizace či procesu. Doménovou autorizaci a konzistenci dat proto ověřujte i v aplikaci a navazujících službách.
Kdy testy opakovat?
Po změně přístupových pravidel, tokenů, exportů, integračního partnera nebo infrastruktury a v plánovaném režimu podle rizik. Nové rozhraní i stará podporovaná verze patří do inventáře. Oprava je dokončená až po ověření původního scénáře a souvisejících cest.
14Zdroje a další postup
OWASP API Security Top 10 je přehled rizik, nikoli certifikát ani úplný přejímací seznam. Konkrétní doporučení v článku doplňují primární specifikace IETF a dokumentace uvedená u jednotlivých tvrzení. Model faktur, kontrolní seznam a rozdělení provozních odpovědností jsou redakční návrh k přizpůsobení projektu.
Začněte jedním citlivým úkonem, například exportem faktur. Sepište identitu, organizaci, akci, data, náklady a chování při chybě. Z tohoto rozhodnutí vytvořte ověřitelný scénář a přiřaďte vlastníka. Postup potom rozšiřte na ostatní rozhraní. Článek neobsahuje měření zranitelností ani potvrzení bezpečnosti konkrétní aplikace.