Měsíce jste strávili budováním elegantního, škálovatelného SaaS produktu. Vaše API je motor pod kapotou, pohání vše od vaší mobilní aplikace po integrace třetích stran, na které spoléhají vaši největší podnikoví zákazníci. Z obchodního hlediska je to výhra. Z hlediska bezpečnosti? Může to být dokořán otevřené dveře.
Zde je nepříjemná pravda: API jsou primárním cílem moderních útočníků. Obvykle nehledají komplexní "Zero Day" exploit, který vyžaduje doktorát z informatiky. Místo toho hledají "breach-ready" zranitelnosti – jednoduché, běžné chyby ve způsobu, jakým API zpracovává data, autentizaci a oprávnění. To jsou mezery, které hackerovi umožňují získat celou vaši uživatelskou databázi nebo smazat účet klienta pouhou změnou čísla v URL adrese.
Pokud spoléháte na manuální Penetration Test jednou ročně, v podstatě pořizujete snímek své bezpečnosti v úterý a předpokládáte, že jste v bezpečí až do příštího úterý následujícího roku. Ve světě CI/CD pipeline, kde se kód nasazuje několikrát denně, je tento "point-in-time" přístup hazard. Každé nové nasazení je šancí zavést novou chybu.
Zůstat napřed vyžaduje změnu myšlení. Musíte přejít od "pouhého splnění požadavků" na shodu k modelu nepřetržitého řízení expozice. Pojďme se ponořit do toho, jak skutečně zabezpečit vaše SaaS API a zastavit zranitelnosti, které vedou k titulkům v novinách.
Pochopení myšlení "Breach-Ready" API
Když bezpečnostní profesionálové mluví o "breach-ready" zranitelnostech, nemluví o teoretických rizicích. Mluví o chybách, které jsou po objevení triviální k zneužití. Pokud útočník dokáže najít způsob, jak získat přístup k datům, která by neměl vidět, aniž by potřeboval heslo nebo sofistikovaný exploit, je takové API breach-ready.
Většina těchto problémů pramení ze skutečnosti, že API jsou navržena primárně pro funkčnost. Vývojáři chtějí, aby data proudila rychle a spolehlivě. Zabezpečení se často jeví jako zpomalovací práh. Nicméně samotná povaha API – vystavování interní logiky webu – je činí neuvěřitelně citlivými.
Přechod od monolitů k mikroslužbám
V dřívějších dobách jste měli jeden velký server. Dali jste kolem něj firewall a většinou jste byli v bezpečí. Nyní se typická SaaS architektura skládá z desítek mikroslužeb komunikujících prostřednictvím API. To zvyšuje vaši "attack surface". Každý jednotlivý koncový bod je potenciálním vstupním bodem. Pokud je jedna služba laxní s autorizací, může se stát slabým článkem, který kompromituje celý cluster.
Iluze "skrytých" koncových bodů
Častou chybou, kterou vidím, je "security through obscurity". Některé týmy věří, že pokud nezdokumentují koncový bod ve své veřejné API dokumentaci, útočníci ho nenajdou. To je zbožné přání. Nástroje jako Ffuf, Gobuster a Burp Suite dokáží objevit skryté koncové body během několika minut pomocí jednoduchého fuzzingu. Pokud koncový bod existuje a není řádně zabezpečen, bude nalezen.
OWASP API Top 10: Kde většina SaaS společností selhává
Pokud chcete vědět, kde jsou mezery, podívejte se na OWASP API Security Top 10. Je to průmyslový standard z dobrého důvodu. Zatímco existuje mnoho technických chyb, ty nejnebezpečnější nejsou o "bugech" v kódu, ale o "chybách" v logice.
BOLA: Král zranitelností API
Broken Object Level Authorization (BOLA) je možná nejčastější a nejškodlivější chyba API. Nastává, když aplikace řádně neověří, zda má uživatel požadující zdroj skutečně oprávnění k přístupu.
Představte si, že vaše API má koncový bod jako tento: https://api.saasapp.com/v1/user/12345/profile.
Pokud jsem přihlášen jako uživatel 67890, ale změním 12345 v URL na 67891, a server mi poskytne profil této osoby, máte zranitelnost BOLA.
Zní to jednoduše, ale děje se to neustále, protože vývojáři často kontrolují, zda je uživatel přihlášen (Authentication), ale zapomínají zkontrolovat, zda vlastní data, která požadují (Authorization).
Nefunkční autentizace uživatelů
Authentication je součástí rovnice "kdo jste". Když je tato část nefunkční, útočníci mohou převzít identity. Mezi běžné chyby patří:
- Slabá validace tokenů: Používání JWT (JSON Web Tokens), které nejsou řádně podepsány nebo mají příliš dlouhou dobu platnosti.
- Nedostatečné omezení rychlosti: Umožnění botovi zkoušet milion kombinací hesel za sekundu na vašem koncovém bodě
/login. - Credential Stuffing: Neschopnost detekovat, když jsou tisíce účtů napadeny známými uniklými hesly z jiných úniků dat.
Nadměrné vystavení dat
Jedná se o klasickou chybu "líného vývojáře". Namísto vytvoření specifického objektu pro přenos dat (DTO) pro odpověď API, backend jednoduše vysype celý záznam databáze do JSON odpovědi a spoléhá na frontend, že odfiltruje to, co uživatel vidí.
Prohlížeč uživatele může zobrazovat pouze "Uživatelské jméno" a "Datum registrace", ale pokud zvědavý uživatel otevře záložku "Síť" ve svých nástrojích prohlížeče, může vidět uživatelovo hašované heslo, domácí adresu a interní systémová ID. Jakmile jsou tato data odeslána klientovi, ztratili jste nad nimi kontrolu.
Nedostatek zdrojů a omezení rychlosti
Pokud vaše API umožňuje komukoli vyžádat 10 000 záznamů na stránku nebo nahrát 2GB soubor do slotu pro profilový obrázek, zveřejňujete se útoku Denial of Service (DoS). Útočník ani nemusí krást data, aby vám ublížil; může jednoduše shodit vaše servery přetížením vašich zdrojů.
Mapování vaší útočné plochy: Nemůžete opravit to, co nevidíte
Než začnete s opravami, musíte přesně vědět, co bráníte. Většina SaaS společností má "zombie API" – staré verze (v1, v2), které měly být vyřazeny, ale stále běží v produkci, aby podporovaly jednoho starého zákazníka. Tyto staré verze jsou zřídka aktualizovány a často obsahují nejzávažnější zranitelnosti.
Nebezpečí Shadow API
Shadow API je koncový bod, který byl vytvořen pro rychlou opravu nebo specifickou integraci a nikdy neprošel formální bezpečnostní kontrolou. Možná vývojář vytvořil koncový bod /debug/get-all-users během stagingu a omylem ho nasadil do produkce. Protože není v oficiální dokumentaci, váš bezpečnostní tým o něm neví, ale skener ho najde během několika sekund.
Jak správně zmapovat vaši plochu
Mapování není jednorázový úkol. Potřebujete proces k identifikaci:
- Každý veřejný koncový bod: Co je vystaveno internetu?
- Interní komunikace služeb: Jak spolu komunikují vaše mikroslužby? (Pokud se útočník dostane dovnitř, může se pohybovat laterálně?)
- Integrace třetích stran: Která API voláte vy a která volají vás?
- Historie verzí: Které verze vašeho API jsou aktuálně aktivní?
Zde manuální audity selhávají. Než auditor dokončí svou zprávu, pravděpodobně jste již nasadili tři nové verze vašeho API. Proto doporučujeme přechod k řízení kontinuální expozice hrozbám (Continuous Threat Exposure Management – CTEM). Platforma jako Penetrify automatizuje tuto fázi průzkumu, neustále mapuje vaši externí útočnou plochu, abyste nemuseli hádat, kde se nacházejí vaše zranitelnosti.
Praktické strategie pro zabezpečení vašeho API
Nyní, když známe rizika, pojďme se bavit o skutečné práci na jejich odstranění. Zabezpečení není jeden nástroj, který si koupíte; je to řada vrstev.
1. Implementujte autorizační model Zero-Trust
Přestaňte předpokládat, že pokud požadavek pochází z „důvěryhodné“ interní sítě nebo má platnou session cookie, je bezpečný. Každý jednotlivý požadavek na každý jednotlivý endpoint musí být autorizován.
- Používejte řízení přístupu založené na politikách (Policy-Based Access Control – PBAC): Namísto jednoduchých rolí (Admin vs. User) používejte politiky, které kontrolují vztah mezi uživatelem a objektem. „Může uživatel X provést akci Y na objektu Z?“
- Centralizujte autorizaci: Nepište autorizační logiku do každého kontroleru. Vytvořte centralizovaný middleware nebo dedikovanou autorizační službu. To výrazně usnadňuje audit a aktualizace.
2. Zpřísněte validaci vstupu a filtrování výstupu
Nikdy nedůvěřujte datům pocházejícím od uživatele. Tečka.
- Přísná schémata: Používejte nástroje jako JSON Schema nebo OpenAPI (Swagger) k vynucení přísných typů. Pokud API očekává celé číslo pro
userIda obdrží řetězec nebo payload SQL Injection, požadavek by měl být okamžitě zamítnut. - Allow-listy namísto Block-listů: Nesnažte se filtrovat „špatné znaky“. Místo toho přesně definujte, jak vypadají „dobrá“ data, a vše ostatní zamítněte.
- Sanitizujte výstupy: Jak bylo zmíněno v sekci „Nadměrná expozice dat“, explicitně definujte, která pole se dostanou do vašich API odpovědí. Použijte dedikovanou vrstvu pro mapování databázových modelů na API odpovědi.
3. Zabezpečte správu tokenů
JWT jsou skvělé, ale často jsou implementovány špatně.
- Krátkodobé přístupové tokeny: Udržujte přístupové tokeny krátké (např. 15 minut) a používejte refresh tokeny k získání nových.
- Bezpečné úložiště: Zajistěte, aby byly tokeny uloženy v
HttpOnlyaSecurecookies, aby se zabránilo útokům Cross-Site Scripting (XSS). - Revokační seznamy: Implementujte způsob, jak okamžitě zneplatnit tokeny, pokud se uživatel odhlásí nebo je zařízení odcizeno.
4. Implementujte inteligentní Rate Limiting
Nenastavujte pouze globální limit (např. 100 požadavků za minutu). To je příliš hrubé.
- Tiered Limiting: Různé limity pro různé endpointy. Váš
/loginendpoint by měl mít mnohem přísnější limity než váš/get-public-postsendpoint. - User-Based & IP-Based Limits: Sledujte požadavky podle ID autentizovaného uživatele i zdrojové IP adresy, abyste zabránili distribuovaným útokům.
- Adaptive Limiting: Použijte systém, který automaticky zpřísňuje limity, když detekuje nárůst chyb 401 (Unauthorized) nebo 404 (Not Found) – klasický znak brute-force nebo fuzzing útoku.
Srovnání: Manual Penetration Testing vs. Kontinuální bezpečnostní testování
Dlouhou dobu byl zlatým standardem každoroční „pen test“. Butiková firma by přišla na dva týdny, pokusila se prolomit vaše systémy a předala vám 50stránkové PDF. I když lidská kreativita má stále svou hodnotu, tento model je pro moderní SaaS nefunkční.
| Funkce | Tradiční Penetration Testing | Kontinuální testování (PTaaS/ODST) |
|---|---|---|
| Frekvence | Ročně nebo čtvrtletně | Denně/Týdně/Na vyžádání |
| Pokrytí | Snímek konkrétní verze | Vyvíjí se s každým nasazením kódu |
| Náklady | Vysoké počáteční náklady na zakázku | Předvídatelné předplatné/využití |
| Zpětná vazba | Týdny po dokončení testu | V reálném čase nebo téměř v reálném čase |
| Náprava | Opraveno v hromadném „bezpečnostním sprintu“ | Opraveno jako součást CI/CD pipeline |
| Riziko | „Slepota v daném okamžiku“ | Neustálá viditelnost expozice |
Pokud jste startup, který se snaží uzavřít obchod s velkým podnikem, klient si vyžádá zprávu z Penetration Testu. Zpráva stará šest měsíců je sotva užitečná. Možnost prokázat, že využíváte platformu pro kontinuální testování, jako je Penetrify, dokazuje vašim zákazníkům, že bezpečnost je nedílnou součástí vaší kultury, nikoli jen kontrolní seznam, který vyplníte jednou ročně.
Integrace bezpečnosti do vašeho DevSecOps pipeline
Cílem je snížit „bezpečnostní tření“. Když je bezpečnost překážkou, která zpomaluje nasazení, vývojáři nacházejí způsoby, jak ji obejít. Tajemství spočívá v přesunutí bezpečnosti „doleva“ – integraci co nejdříve do životního cyklu vývoje.
DevSecOps Workflow
Namísto čekání, až bezpečnostní tým najde chybu v produkci, vytvořte pipeline, která ji zachytí dříve, než opustí počítač vývojáře.
- IDE Pluginy: Používejte lintovací nástroje a bezpečnostní pluginy (jako Snyk nebo SonarQube), které zvýrazňují zranitelné vzory kódu, jak je vývojář píše.
- Pre-commit Hooks: Spouštějte základní skripty, které kontrolují, zda v kódu nezůstaly náhodou citlivé údaje (jako API klíče), ještě předtím, než je kód odeslán na GitHub.
- Automatické skenování v CI: Pokaždé, když je otevřen Pull Request, spusťte automatické skenování zranitelností. Pokud je nalezena „Kritická“ nebo „Vysoká“ zranitelnost, sestavení by mělo automaticky selhat.
- Dynamická analýza (DAST): Jakmile je kód v testovacím prostředí, spusťte automatizované testy, které interagují s běžícím API, aby nalezly logické chyby, BOLA a konfigurační chyby.
- Kontinuální monitorování: I po nasazení pokračujte ve skenování. Nové zranitelnosti ve vašich závislostech (jako situace s Log4j) se mohou objevit přes noc.
Řešení False Positives
Největší stížností na automatizované nástroje je „šum“. Pokud nástroj označí 100 „zranitelností“ a 95 z nich je irelevantních, vývojáři začnou ignorovat upozornění.
Klíčem je používat nástroj, který poskytuje praktické pokyny k nápravě. Namísto pouhého konstatování „Zde máte zranitelnost BOLA“ by měl nástroj vysvětlit, proč je to riziko, a poskytnout příklad kódu, jak ji opravit. To promění bezpečnostní upozornění v příležitost k učení pro vývojáře.
Scénář z reálného světa: „Tichý“ únik API
Podívejme se na hypotetický (ale velmi realistický) scénář.
Společnost X je FinTech SaaS. Mají funkci, kde si uživatelé mohou prohlížet své měsíční výkazy útraty. API endpoint je /api/reports/{report_id}.
Vývojáři implementovali kontrolu, aby se ujistili, že je uživatel přihlášen. Skvělé. Zapomněli však zkontrolovat, zda {report_id} skutečně patří přihlášenému uživateli.
Útočník to objeví. Napíše jednoduchý Python skript, který prochází čísla report_id od 1 000 000 do 2 000 000. Za méně než hodinu útočník stáhl 1 milion soukromých finančních zpráv.
Proč se to stalo?
- Manuální Penetration Test byl proveden v lednu.
- Funkce zpráv byla přidána v březnu.
- Kontrola "přihlášení" se vývojáři zdála jako "dostatečné zabezpečení".
- Na endpointu pro zprávy nebylo žádné omezení rychlosti, takže skript běžel nezjištěn.
Jak se tomu dalo zabránit?
- Kontrola BOLA: Jednoduchý řádek kódu:
if (report.userId != currentUser.id) throw Unauthorized(); - Omezení rychlosti: Systém by měl označit účet, který požaduje 1 000 zpráv za 60 sekund.
- Kontinuální testování: Automatizovaný nástroj skenující API by se pokusil změnit ID a označil by zranitelnost BOLA v okamžiku, kdy by kód dorazil do staging prostředí.
Časté chyby při zabezpečování SaaS API
I s těmi nejlepšími úmysly týmy často padají do těchto pastí:
Spoléhání se výhradně na WAF
Web Application Firewall (WAF) je skvělý nástroj pro zastavení generických útoků (jako je SQL Injection nebo běžné vzorce botů). WAF však nemůže zastavit útok BOLA. Pro WAF vypadá požadavek na /api/reports/123 přesně jako požadavek na /api/reports/124. Nemá žádný kontext, kdo vlastní kterou zprávu. Nezaměňujte WAF za komplexní bezpečnostní strategii.
Překomplikování systému API klíčů
Některé týmy vytvářejí neuvěřitelně složité systémy rotace a správy API klíčů, ale zapomínají implementovat základní autorizaci. Efektní klíč nezáleží, pokud endpoint, který odemyká, umožňuje uživateli přístup k datům kohokoli. Udržujte svou autentizaci jednoduchou a autorizaci přísnou.
Ignorování API dokumentace (nebo její přílišné detailování)
Zatímco byste se neměli spoléhat na "skrytá" API, neměli byste ani umisťovat citlivé interní implementační detaily do vaší veřejné Swagger dokumentace. Zaměřte svou dokumentaci na to, jak API používat, nikoli na to, jak funguje interně.
Zanedbávání aktualizací závislostí
Vaše API není jen kód, který jste napsali; je to 500 knihoven, které jste importovali přes NPM nebo Maven. Pokud jedna z těchto knihoven má známou zranitelnost, celé vaše API je v ohrožení. Používejte nástroje ke sledování vašeho Software Bill of Materials (SBOM) a pravidelně aktualizujte závislosti.
Pokročilé vyhledávání hrozeb pro API
Jakmile zvládnete základy, je čas přejít z obranného postoje k proaktivnímu vyhledávání hrozeb. To znamená myslet jako útočník, abyste našli mezery dříve, než je najdou oni.
Testování chyb "obchodní logiky"
Automatizované skenery jsou skvělé při hledání technických chyb, ale potýkají se s obchodní logikou. Chyba obchodní logiky nastává, když API funguje přesně tak, jak bylo naprogramováno, ale samotný kód umožňuje zneužití.
Příklad: Představte si API "Doporučte příteli", které vám dává kredit 10 $. Útočník zjistí, že může volat API se svou vlastní e-mailovou adresou jako "přítelem", čímž si efektivně tiskne peníze. Žádný skener to neoznačí jako "zranitelnost", protože se jedná o platné volání API. K identifikaci těchto okrajových případů potřebujete přístup zaměřený na člověka.
Monitorování anomálií
Zabezpečení není jen o prevenci; je to o detekci. Musíte vědět, kdy se děje něco zvláštního.
- Nárůsty chyb 4xx: Náhlý nárůst chyb
403 Forbiddennebo404 Not Foundobvykle znamená, že někdo testuje vaše API, aby našel skryté koncové body. - Geografické anomálie: Pokud je 99 % vašich uživatelů v USA, ale zaznamenáte masivní nárůst provozu z datového centra v jiné zemi, je to varovný signál.
- Objem odchozích dat: Pokud typický uživatelský požadavek vrátí 2 KB dat, ale vidíte sérii požadavků vracejících 2 MB každý, někdo by mohl stahovat vaši databázi.
Cesta k souladu: SOC2, HIPAA a PCI-DSS
Pro mnoho SaaS společností není zabezpečení jen o zastavení hackerů – je to o úspěšném absolvování auditů. Ať už jde o SOC2 pro důvěru podniků, HIPAA pro zdravotnictví, nebo PCI-DSS pro platby, požadavky jsou podobné: musíte prokázat, že máte konzistentní proces pro identifikaci a opravu zranitelností.
Přechod od „jednorázového“ k „průběžnému“ souladu
Auditoři si začínají uvědomovat, že roční Penetration Test je nedostatečný. Chtějí vidět důkazy o:
- Pravidelné skenování zranitelností: Důkaz, že často kontrolujete slabá místa.
- Časové osy nápravy: Důkaz, že pokud je nalezeno „vysoké“ riziko, je opraveno v určitém časovém rámci (např. do 30 dnů).
- Řízení změn: Dokumentace prokazující, že zabezpečení bylo zohledněno během vývoje nových funkcí.
Používáním platformy jako Penetrify generujete nepřetržitou stopu důkazů. Namísto měsíčního shánění podkladů pro přípravu na audit můžete jednoduše poskytnout zprávu ukazující vaši bezpečnostní pozici za poslední rok a vaši historii nápravy objevených nedostatků.
Konečný kontrolní seznam pro zabezpečení API
Pokud si nejste jisti, kde začít, použijte tento kontrolní seznam. Nesnažte se to všechno udělat za jeden den; vyberte si jednu kategorii a věnujte se jí během jednoho sprintu.
✅ Autorizace a autentizace
- Každý koncový bod má explicitní kontrolu autorizace.
- BOLA je testována pro všechny zdroje, které používají ID v URL.
- Tokeny mají krátkou životnost a jsou bezpečně uloženy.
- Omezení rychlosti je implementováno na všech citlivých koncových bodech (přihlášení, reset hesla, export dat).
✅ Integrita dat
- V odpovědích API neunikají žádná interní databázová pole.
- Validace vstupu je vynucena přísným schématem (žádné „důvěřování“ klientovi).
- Veškerá komunikace API je vynucena přes TLS (HTTPS).
✅ Viditelnost a monitorování
- Všechny koncové body API jsou mapovány a dokumentovány.
- Pro všechny chyby 4xx a 5xx je zavedeno logování.
- Jsou nastaveny výstrahy pro anomální vzorce provozu.
✅ Procesy a nástroje
- Bezpečnostní skenování je integrováno do CI/CD pipeline.
- Kritické závislosti jsou aktualizovány týdně/měsíčně.
- Je zavedeno řešení pro kontinuální testování (jako Penetrify) k zachycení „driftu“.
Přestaňte hádat, začněte testovat
Realita zabezpečení SaaS je taková, že nikdy nebudete 100% „zabezpečeni“. Vždy existuje nový exploit nebo nová chyba v konfiguraci. Rozdíl mezi společnostmi, které přežijí narušení, a těmi, které zaniknou, je průměrná doba do nápravy (MTTR).
Pokud zranitelnost existuje ve vašem API šest měsíců, než ji objevíte, jste snadný cíl. Pokud ji najdete do šesti hodin od nasazení kódu, je to jen chyba, která byla zachycena.
Přestaňte se spoléhat na naději "jednou za rok". Přestaňte předpokládat, že vaše koncové body jsou skryté. Bezpečnost je živý proces a vaše testování by mělo být stejně dynamické jako váš kód.
Pokud vás unavuje úzkost, která doprovází každé hlavní vydání, je čas přejít na model testování bezpečnosti na vyžádání. Penetrify překlenuje propast mezi jednoduchým skenerem a drahou manuální firmou a poskytuje vám nepřetržitou viditelnost, kterou potřebujete k škálování vašeho SaaS, aniž byste nechali otevřené dveře útočníkům.
Nečekejte na oznámení o narušení, abyste si uvědomili, že vaše API bylo na něj připraveno. Zabezpečte svůj perimetr ještě dnes.
Časté dotazy: Běžné otázky o bezpečnosti API
Otázka: Již používáme WAF. Potřebujeme stále Penetration Testing?
Odpověď: Ano. WAF je jako bezpečnostní stráž u předních dveří, která kontroluje známé špatné aktéry. Penetration Testing (zejména automatizované, nepřetržité testování) je jako kontrola, zda jsou okna zamčená a zda jsou zadní dveře pootevřené. WAF zastaví běžné "útoky", ale nenajde "zranitelnosti" ve vaší logice, jako je BOLA nebo nadměrná expozice dat.
Otázka: Je automatizované Penetration Testing stejně dobré jako lidský expert?
Odpověď: Je to jiné. Lidští experti jsou lepší v hledání komplexních, vícestupňových chyb obchodní logiky. Lidé jsou však pomalí a drazí. Automatizované platformy jsou lepší v hledání "nízko visícího ovoce", které útočníci skutečně používají – chybných konfigurací a běžných OWASP chyb – a dělají to 24/7. Nejlepším přístupem je hybridní: nepřetržitá automatizace pro většinu práce a cílené lidské audity pro vysoce rizikové funkce.
Otázka: Jak často bych měl skenovat své API?
Odpověď: Ideálně pokaždé, když změníte kód. V moderním DevSecOps prostředí jsou bezpečnostní skeny spouštěny "git push" nebo "merge requestem". Pokud ještě nejste na této úrovni, jednou týdně je dobrý výchozí bod. Cokoli déle než měsíc zanechává obrovské okno rizika.
Otázka: Zpomalí automatizované skenování výkon mého API?
Odpověď: Pokud je správně nakonfigurováno, ne. Většina profesionálních platforem vám umožňuje skenovat stagingové prostředí, které zrcadlí produkci, což znamená nulový dopad na vaše koncové uživatele. I při skenování produkce lze nástroje omezit, aby se zajistilo, že neovlivní výkon.
Otázka: Co bych měl opravit jako první, pokud mám omezené zdroje?
Odpověď: Zaměřte se na BOLA (Broken Object Level Authorization). Je to nejčastější zranitelnost s vysokým dopadem v SaaS API. Zajistěte, aby pokaždé, když uživatel požádá o zdroj podle ID, zkontrolovali, zda skutečně vlastní tento zdroj. Je to malá změna kódu, která zabraňuje drtivé většině katastrofálních úniků dat.