Bezpečnosť API: autentifikácia, limity a ochrana údajov
Platný token ešte neznamená oprávnenie ku každému záznamu. Bezpečné API musí pri požiadavke overiť identitu, povolenú akciu, konkrétne údaje aj prijateľné náklady. Potrebuje tiež pravidlá pre kľúče, logy a zmeny. Tento sprievodca ukazuje, čo požadovať pri návrhu a ako výsledok overiť na modelovom firemnom rozhraní.
API je dohoda, ako spolu systémy komunikujú. Môže čítať faktúry, meniť objednávky alebo spúšťať platenú službu. Chyba preto nemusí znamenať iba nedostupnú stránku: môže sprístupniť údaje inej firmy alebo vytvoriť náklad, ktorý si tím všimne až vo vyúčtovaní. Samotné HTTPS ani prihlasovacia obrazovka všetky tieto situácie neriešia.
Všeobecný postup prepojenia opisuje sprievodca API integráciami. Tu sa zameriame na hranice prístupu a prevádzky vlastného API vrátane systému pre viac zákazníckych organizácií. Príklady sú ilustratívne, nie výsledky klientského auditu. Primárne podklady OWASP a IETF sme overili 28. októbra 2026.
01Spíšte rozhrania, údaje a zodpovednosť
Začnite zoznamom skutočne dostupných rozhraní. OWASP upozorňuje na riziko neúplného inventára, najmä zabudnutých verzií a testovacích prostredí. Pri každej časti určte vlastníka, účel, klientov, typ údajov a plán ukončenia podpory. Dokumentácia novej verzie neznamená, že stará adresa prestala odpovedať.
Do prehľadu patria aj exporty, administrácia, webhooky, dávkové importy a úlohy na pozadí. Spíšte, kto údaje poskytuje, kto ich dostáva a kedy vzniká platená operácia. Pri externom dodávateľovi rozlišujte zodpovednosť za jeho službu a za vaše použitie. Kľúč s nadmernými právami je vaše riziko aj vtedy, keď dodávateľ funguje správne.
Výstupom má byť krátka mapa a súbor rozhodnutí, nielen zoznam URL. Kto smie obnoviť prístup? Kto schvaľuje nový export? Kto zastaví problémovú integráciu? Bez týchto odpovedí sa technická ochrana ťažko prevádzkuje. Najprv riešte rozhrania, ktoré môžu sprístupniť cudzie údaje alebo vykonať významnú zmenu.
02Autentifikácia a autorizácia odpovedajú na iné otázky
Autentifikácia overuje predloženú identitu alebo prihlasovací prostriedok. Autorizácia rozhoduje, čo daný subjekt smie urobiť. OWASP odporúča minimálne oprávnenia, predvolené zamietnutie a kontrolu každej požiadavky. Prihlásený účet preto nemá automaticky nárok na všetky faktúry ani na každú administratívnu funkciu.
| Kontrola | Otázka | Príklad rozhodnutia |
|---|---|---|
| Autentifikácia | Komu alebo čomu patrí overený prístup? | Token patrí konkrétnemu klientovi a používateľovi, ak ho zastupuje. |
| Funkcia | Smie tento subjekt vykonať akciu? | Čitateľ nesmie schváliť platbu. |
| Objekt | Smie pracovať práve s týmto záznamom? | Faktúra patrí dostupnej organizácii a oprávnenému rozsahu. |
| Vlastnosti | Ktoré polia smie čítať alebo meniť? | Bežná aktualizácia profilu nemôže prideliť správcu. |
Rozhodnutie patrí na server. Skryté tlačidlo alebo filter vo frontendovej aplikácii iba upravuje používateľské rozhranie. Rovnakú operáciu môže zavolať iný klient. Prístupové pravidlá formulujte jazykom domény: napríklad účtovník smie čítať faktúry pridelených pobočiek, ale nesmie meniť bankový účet dodávateľa. To je presnejšie než neurčité „používateľ má prístup do systému“.
03Prihlasovací mechanizmus vyberte podľa typu klienta
Rozlišujte človeka používajúceho aplikáciu a službu komunikujúcu so službou. OAuth 2.0 rieši delegovaný prístup; OpenID Connect nad ním pridáva overenie identity používateľa. Pri autorizačnom toku s kódom vychádzajte z RFC 9700 vrátane PKCE pre verejných klientov. Nevytvárajte vlastný prihlasovací protokol iba kvôli kratšej implementácii.
API kľúč môže identifikovať integráciu, ale sám nemusí určiť konkrétneho človeka, jeho rolu ani organizáciu. Každej integrácii prideľte samostatný prístup a potrebný rozsah. Tajný kľúč vložený do verejného JavaScriptu alebo distribuovanej mobilnej aplikácie nemožno považovať za dôverné serverové tajomstvo. Architektúra musí počítať s tým, kde sa klient skutočne spúšťa.
JWT je formát tokenu, nie úplné bezpečnostné riešenie. Podľa odporúčaní IETF pre JWT overujte kryptografiu, dôveryhodného vydavateľa a zamýšľaného príjemcu; kontrolujte aj časovú platnosť podľa použitého profilu. Podpísaný token nie je automaticky šifrovaný. ID token na prihlásenie nezamieňajte za prístupový token pre API.
04Každý záznam musí prejsť kontrolou oprávnenia
Broken Object Level Authorization označuje chýbajúcu alebo nesprávnu kontrolu prístupu ku konkrétnym objektom. Zmena číselného ID na UUID tento problém sama neopraví. Server musí rozhodnúť, či overený subjekt smie s požadovaným záznamom pracovať, a to pri čítaní, zmene, mazaní aj exporte.
Modelový systém vedie faktúry firiem A a B. Účtovník firmy A smie čítať vybrané faktúry A. Test so správnym tokenom a faktúrou A teda môže uspieť. Rovnaký účet s identifikátorom faktúry B musí byť odmietnutý bez sprístupnenia jej obsahu. Je to očakávaný výsledok testu, nie tvrdenie, že sme takúto chybu našli na skutočnom webe.
Do pravidla môže vstupovať aj pobočka, pridelenie zákazky alebo stav dokumentu. Prístup iba podľa zhodného ID používateľa preto nemusí stačiť. Rovnakú politiku použite pri detaile, zozname, vyhľadávaní aj dávkovej akcii. Ak chránite detail, no export vyberie všetky riadky, hranica prístupu zostala otvorená.
05Organizácie oddeľte aj v cache a úlohách na pozadí
V systéme pre viac zákazníkov znamená tenant samostatnú zákaznícku organizáciu. OWASP opisuje izoláciu tenantov naprieč údajmi, cache aj spracovaním. Identifikátor organizácie z požiadavky sám nedokazuje členstvo. Overte väzbu na prihlásený subjekt a bezpečne preneste tento kontext do nadväzujúcich operácií.
Cache faktúry musí rozlišovať všetky okolnosti, ktoré menia obsah alebo oprávnenia, napríklad organizáciu a rozsah používateľa. Oddelený kľúč cache pritom nenahrádza autorizáciu. Rovnako dôležitý je rad úloh: úloha vytvorená pre firmu A sa nesmie spracovať v kontexte firmy B. Kontrolujte aj súbory, vyhľadávací index a odkazy na stiahnutie.
Určte, čo sa stane pri odobratí členstva alebo zmene roly počas čakania úlohy. Pri citlivej operácii môže byť potrebné znovu overiť aktuálne oprávnenie pri spustení a pri stiahnutí výsledku. Samostatná databáza môže posilniť izoláciu, ale neopraví chybný výber zákazníka v aplikácii. Každá vrstva potrebuje zodpovedajúci dôkaz.
06Povoľujte konkrétne polia a obchodné operácie
OWASP rozlišuje aj oprávnenia na úrovni vlastností objektu. API nemá automaticky vracať celý databázový záznam ani ukladať každé pole prijatého objektu. Pre jednotlivé operácie určte povolené vstupné a výstupné polia. Technicky platný JSON môže obsahovať zmenu, ktorú daný používateľ vykonať nesmie.
Pri modelovom profile možno povoliť meno a telefón, zatiaľ čo rola správcu a schválenie účtu majú vlastný riadený postup. Pri faktúre môže zákazník vidieť sumu a splatnosť, ale nemusí mať prístup k internej poznámke. Odstránenie poľa až vo frontendovom zobrazení údaje nechráni: ak ich server odoslal, klient ich už získal.
Overujte aj stav procesu. Oprávnenie vytvoriť návrh nemusí znamenať oprávnenie ho schváliť a zaplatený doklad nemusí dovoľovať rovnakú zmenu ako koncept. Pravidlá musia obstáť pri inej HTTP metóde, dávkovom rozhraní aj novej verzii API. Dôležité prechody riešte explicitne a atomicky podľa potrieb domény.
07Prevádzkové limity a kvóty majú odlišný účel
V návrhu rozlišujte rýchlosť požiadaviek, súbežnú prácu a celkovú spotrebu. Rate limit zvyčajne chráni tempo v určenom časovom okne. Kvóta tu znamená pridelený objem za dlhšie obdobie alebo rozpočet. Názvoslovie dodávateľov sa líši, preto opíšte konkrétne pravidlo, jednotku, vlastníka a správanie po vyčerpaní.
| Ochrana | Čo obmedzuje | Čo overiť |
|---|---|---|
| Rate limit | Tempo požiadaviek pre klienta, účet alebo operáciu. | Krátka špička a bežná prevádzka majú predvídateľný výsledok. |
| Kvóta | Celkový objem alebo rozpočet zákazníka za obdobie. | Viac kľúčov jednej firmy neobíde spoločnú kvótu. |
| Súbeh | Počet súčasne bežiacich náročných úloh. | Ďalší export nezablokuje interaktívne požiadavky. |
| Veľkosť a náročnosť | Telo požiadavky, počet položiek alebo rozsah výpočtu. | Jediná prijatá požiadavka nemôže spustiť neobmedzenú prácu. |
Pre priveľa požiadaviek definuje RFC 6585 stav 429; odpoveď môže uviesť Retry-After. Klient potrebuje obmedzené opakovanie s prestávkou, aby problém nezhoršoval. Limit iba podľa IP môže spojiť rôznych zákazníkov za jednou sieťou. Pri distribuovanom API overte, že súčet limitov na jednotlivých inštanciách neumožní prekročiť zamýšľanú spoločnú hranicu.
08Chráňte aj náklady jednej požiadavky
OWASP API4 zahŕňa nielen CPU a pamäť, ale aj platené externé operácie. Jedna požiadavka môže rozoslať veľa správ alebo vytvoriť rozsiahly export. Obmedzenie počtu volaní preto doplňte limitom položiek, časom spracovania, stránkovaním a kontrolou počtu nadväzujúcich úkonov. Drahé operácie majú mať vlastné pravidlá.
Pred spustením platenej práce rezervujte kapacitu alebo rozpočet spôsobom, ktorý obstojí pri súbehu. Samotné prečítanie zostatku a neskoršie odpočítanie môže viacerým požiadavkám dovoliť spotrebovať rovnakú rezervu. Pri neúspechu určte, čo sa uvoľní a aký náklad už skutočne vznikol. Zákazník má rozoznať čakanie, odmietnutie a dokončenie.
Limity overujte spolu s výkonom databázy a API. Timeout u klienta nezaručuje ukončenie práce na serveri. Sledujte aj rady úloh a nadväzujúce služby. Idempotentné spracovanie pomôže obmedziť duplicitné účinky opakovania, ale kľúč idempotencie musí mať správny rozsah klienta a operácie a nenahrádza kontrolu oprávnení.
09Kľúče potrebujú vlastníka a celý životný cyklus
OWASP Secrets Management rozlišuje vytvorenie, rotáciu, odvolanie a expiráciu tajomstiev. Pri každom prístupe evidujte účel, vlastníka, oprávnenia a prostredie. Produkcia a test nemajú zdieľať jeden kľúč. Tajomstvá poskytujte aplikácii riadenou cestou a neposielajte ich do dokumentácie, repozitára ani bežných logov.
Pri plánovanej rotácii môže pomôcť krátke riadené prekrytie starého a nového kľúča. Potvrďte prechod všetkých klientov a starý prístup odvolajte. Pri podozrení na únik má prednosť obmedzenie zneužitia; nenechávajte kompromitovaný kľúč aktívny iba pre pohodlie migrácie. Pripravte postup tak, aby výmena nevyžadovala improvizáciu počas incidentu.
Krátka platnosť tokenu obmedzuje časové okno, no nemusí znamenať okamžité odvolanie. Vopred rozhodnite, ako zastavíte už vydané prístupy a ako rýchlo sa zmena prejaví vo všetkých službách. Riešenie závisí od typu tokenu a infraštruktúry. Samotné vytvorenie nového tajomstva nestačí, ak sa staré naďalej prijíma.
10Validujte vstupy, výstupy a externé udalosti
OWASP REST Security odporúča HTTPS, kontrolu vstupov a bezpečné zaobchádzanie s citlivými údajmi. Overujte typy, rozsahy, povolené metódy aj veľkosť vstupu. CORS je pravidlo pre prehliadače, nie autorizácia serverového klienta. Pri autentifikácii cez cookies riešte zodpovedajúcu ochranu proti CSRF. Konfiguráciu vyberajte podľa konkrétneho toku.
Webhook musí overiť pôvod aj spracovanie udalosti. Napríklad Stripe dokumentuje podpisy, opakovanie a duplicitné udalosti. Použite odporúčané overenie dodávateľa nad správnymi údajmi, kontrolu časového kontextu a ochranu pred opakovaným účinkom. Overený podpis nedokazuje, že udalosť patrí správnemu zákazníkovi alebo smie zmeniť ľubovoľnú objednávku.
Ak API sťahuje súbor z adresy dodanej klientom, posúďte riziko SSRF. Obmedzte dostupné ciele a odchádzajúcu komunikáciu vrátane presmerovaní a interných služieb. Aj odpoveď dôveryhodného partnera je vstup, ktorý potrebuje validáciu a rozumné limity. Integrácia nemá automaticky dôverovať všetkému, čo partner vráti.
11Logy majú vysvetliť udalosť bez ďalšieho úniku
OWASP Logging odporúča zaznamenávať bezpečnostne významné udalosti a chrániť samotné záznamy. Na prevádzkové vyšetrovanie zvyčajne potrebujete čas, identifikátor požiadavky, subjekt, organizáciu, operáciu a výsledok. Nepridávajte celé tokeny, heslá ani kompletné telá požiadaviek iba preto, že sa ľahko zapisujú. Citlivý obsah obmedzte podľa skutočnej potreby.
Sledujte napríklad opakované zamietnutia prístupu medzi organizáciami, nezvyčajné exporty a náhly rast platených operácií. Samotný počet chýb nemusí odlíšiť útok od chybného klienta, preto pridajte kontext a zodpovednosť za vyhodnotenie. Alarm bez príjemcu a postupu riešenia je iba ďalšia správa. Otestujte aj situáciu, keď prestane fungovať zber logov.
Incidentný postup má vedieť obmedziť dotknutý prístup, zachovať podklady a určiť rozsah dopadu. Zastavenie celého API nemusí byť prvá voľba, ak možno bezpečne vypnúť konkrétnu integráciu. Zároveň nesľubujte zachovanie prevádzky za každú cenu. O prípadných oznamovacích povinnostiach rozhodujte podľa skutočnej udalosti a relevantných pravidiel.
12Preberajte overené scenáre, nie zoznam technológií
Pred odovzdaním pripravte testovacie účty so skutočne odlišnými rolami a organizáciami a neprodukčné údaje. Pri každom scenári určte očakávaný výsledok, prostredie a dôkaz. Nestačí, že správny používateľ uspeje. Potrebujete preukázať aj zamietnutie nepovolenej operácie bez vedľajšieho účinku a bez úniku citlivých údajov.
- Účet firmy A nezíska detail, zoznam ani export neverejných údajov firmy B.
- Rola na čítanie nemôže zapisovať a bežná zmena profilu nemôže prideliť správcu.
- Neplatný, expirovaný alebo odvolaný prístup zlyhá podľa stanovenej politiky.
- Obmedzenie obstojí pri súbehu, viacerých kľúčoch aj inštanciách služby.
- Duplicitná udalosť nevykoná rovnakú obchodnú zmenu znovu.
- Logy pomôžu dohľadať rozhodnutie a neobsahujú prístupové tajomstvá.
- Po zmene roly, novej verzii alebo úprave exportu sa príslušné testy zopakujú.
Výsledok spojte s konkrétnou opravou a následným overením. Bezpečnostný audit API môže preveriť dôležité hranice, no prevádzková zodpovednosť zostáva priebežnou prácou tímu. Do zadania zahrňte rozsah, testované roly, obmedzenia kontroly a plán opráv. Nákup brány alebo knižnice sám osebe nie je dôkazom pripravenosti.
13Časté otázky
Stačí API chrániť pomocou HTTPS?
HTTPS chráni komunikáciu pri prenose. Nerozhoduje, či overený účet smie čítať konkrétnu faktúru alebo meniť dané pole. Potrebujete aj autorizáciu, vhodné limity, kontrolu vstupov a správu prístupov. Jednotlivé vrstvy riešia odlišné situácie.
Je JWT bezpečnejší než nepriehľadný token?
Samotný formát bezpečnosť neurčuje. Záleží na overovaní, uložení, rozsahu oprávnení, platnosti a možnosti odvolania. JWT môže niesť čitateľné údaje a jeho podpis neznamená šifrovanie. Riešenie vyberte podľa architektúry a prevádzkových požiadaviek.
Ochráni UUID pred prístupom k cudzím údajom?
Ťažšie odhadnuteľný identifikátor môže sťažiť niektoré pokusy, ale nenahrádza oprávnenie. ID sa môže objaviť v odkaze, logu alebo odpovedi. Server musí odmietnuť nepovolený prístup aj vtedy, keď klient správny identifikátor pozná.
Aký rate limit máme nastaviť?
Univerzálne číslo neexistuje. Rozlišujte bežné čítanie, export a platenú operáciu. Vychádzajte z merania kapacity, obvyklého používania a prijateľného nákladu. Uveďte jednotku, časové okno, subjekt a správanie klienta po prekročení. Hranicu overte pri súbehu.
Môžeme dať všetkým integráciám jeden spoločný kľúč?
Oddelené prístupy uľahčia minimálne oprávnenia, dohľadanie pôvodu a odvolanie jedinej integrácie. Spoločný kľúč tieto možnosti obmedzuje a jeho výmena zasiahne viac klientov. Každý prístup má mať vlastníka, účel a známy postup ukončenia.
Vyrieši bezpečnosť API gateway?
Brána môže overovať tokeny, filtrovať požiadavky a riadiť niektoré limity. Zvyčajne však sama nepozná všetky pravidlá konkrétnej faktúry, organizácie či procesu. Doménovú autorizáciu a konzistenciu údajov preto overujte aj v aplikácii a nadväzujúcich službách.
Kedy testy opakovať?
Po zmene prístupových pravidiel, tokenov, exportov, integračného partnera alebo infraštruktúry a v plánovanom režime podľa rizík. Nové rozhranie aj stará podporovaná verzia patria do inventára. Oprava je dokončená až po overení pôvodného scenára a súvisiacich ciest.
14Zdroje a ďalší postup
OWASP API Security Top 10 je prehľad rizík, nie certifikát ani úplný preberací zoznam. Konkrétne odporúčania v článku dopĺňajú primárne špecifikácie IETF a dokumentácia uvedená pri jednotlivých tvrdeniach. Model faktúr, kontrolný zoznam a rozdelenie prevádzkových zodpovedností sú redakčný návrh na prispôsobenie projektu.
Začnite jedným citlivým úkonom, napríklad exportom faktúr. Spíšte identitu, organizáciu, akciu, údaje, náklady a správanie pri chybe. Z tohto rozhodnutia vytvorte overiteľný scenár a priraďte vlastníka. Postup potom rozšírte na ostatné rozhrania. Článok neobsahuje meranie zraniteľností ani potvrdenie bezpečnosti konkrétnej aplikácie.