API jsou základem moderní softwarové architektury. Pohánějí vaše mobilní aplikace, propojují vaše mikroslužby, umožňují integrace třetích stran a slouží jako primární datová transportní vrstva pro celou vaši platformu. Zároveň představují nejrychleji rostoucí útočný vektor v oblasti kybernetické bezpečnosti – přičemž počet narušení souvisejících s API rok od roku dramaticky roste.
Výzva: API jsou pro uživatele neviditelné, ale pro útočníky plně viditelné. Každý koncový bod je potenciálním vstupním bodem. Každý parametr je potenciálním injekčním vektorem. A chyby v obchodní logice, které se nacházejí v pracovních postupech API, jsou ty, které automatizované skenery nejúplněji přehlížejí.
Proč jsou API novou frontovou linií
Moderní aplikace jsou API-first. Webové rozhraní je tenký frontend; API dělají skutečnou práci – ověřují uživatele, načítají data, zpracovávají transakce, spravují oprávnění. Útočník, který rozumí vašemu API, může zcela obejít frontend a komunikovat přímo s vaší backendovou logikou strojovou rychlostí.
Zranitelnosti API jsou obzvláště nebezpečné, protože často odhalují surová data a obchodní operace bez zábran uživatelského rozhraní. Webový formulář může omezit vstup na rozbalovací nabídku; podkladové API může přijmout libovolnou hodnotu. UI může skrýt funkce administrátora; koncový bod API může být přístupný jakémukoli ověřenému uživateli, který zná URL.
OWASP API Security Top 10
OWASP API Security Top 10 poskytuje rámec pro nejkritičtější rizika API: Broken Object Level Authorisation (BOLA), Broken Authentication, Broken Object Property Level Authorisation, Unrestricted Resource Consumption, Broken Function Level Authorisation, Unrestricted Access to Sensitive Business Flows, Server-Side Request Forgery, Security Misconfiguration, Improper Inventory Management a Unsafe Consumption of APIs.
BOLA (také známý jako IDOR – Insecure Direct Object Reference) je trvale nejkritičtější a nejvíce zneužívaná zranitelnost API. Vyskytuje se, když koncový bod API přijme identifikátor objektu (jako je ID uživatele nebo ID záznamu) a vrátí data bez ověření, zda je ověřený uživatel oprávněn k přístupu ke konkrétnímu objektu. Manipulace s identifikátorem vrátí data jiného uživatele – často triviálně.
Rozsah testů API
Komplexní API Penetration Testing by měl pokrývat každý exponovaný koncový bod – nejen ty ve vaší veřejné dokumentaci API. Shadow API (koncové body, které existují v kódu, ale nejsou dokumentovány), zastaralé koncové body, které jsou stále přístupné v produkci, a interní API exponované prostřednictvím chybně nakonfigurovaných síťových pravidel, to vše jsou vysoce hodnotné cíle. Testování by mělo zahrnovat rozhraní REST, GraphQL, gRPC a WebSocket podle potřeby.
Ověřování a Autorizace
Testování ověřování a autorizace API ověřuje, zda každý koncový bod vynucuje správné řízení přístupu. Může standardní uživatel přistupovat ke koncovým bodům administrátora? Může uživatel A načíst data uživatele B? Validuje API správně tokeny, vynucuje vypršení platnosti a zpracovává odvolání? Existují koncové body, které přijímají požadavky bez jakéhokoli ověření?
Testování BOLA/IDOR
Testování BOLA je systematické: pro každý koncový bod, který přijímá identifikátor objektu, tester nahradí identifikátory patřící jiným uživatelům/tenantům a ověří, zda API požadavek odmítne. Zní to jednoduše, ale vyžaduje to testování každého koncového bodu, každého parametru a každé metody HTTP – proces, který vyžaduje jak automatizované nástroje pro pokrytí, tak manuální analýzu pro složité případy.
Omezení rychlosti a prevence zneužití
API bez řádného omezení rychlosti jsou zranitelné vůči útokům credential stuffing, data scraping, denial of service a brute-force útokům. Testování by mělo ověřit, zda jsou limity rychlosti vynucovány konzistentně napříč koncovými body, zda je nelze obejít manipulací s hlavičkami nebo rotací IP adres, a zda mechanismy detekce zneužití skutečně spustí, když by měly.
Specifická rizika GraphQL
GraphQL API představují jedinečná rizika: introspekční dotazy, které odhalují celé schéma, hluboce vnořené dotazy, které způsobují denial of service, dávkové dotazy, které obcházejí omezení rychlosti, a kontroly autorizace, které jsou nekonzistentně aplikovány napříč řešiteli. Testování GraphQL vyžaduje specializované znalosti nad rámec standardního testování REST API.
Reporting a shoda
API Penetration Testing od Penetrify pokrývá rozhraní REST, GraphQL a gRPC s hybridním automatizovaným + manuálním přístupem, který zachytí jak vzory OWASP API Top 10, tak chyby specifické pro obchodní logiku, které jsou jedinečné pro pracovní postupy vašeho API. Zprávy mapované na shodu propojují každé zjištění s kontrolami SOC 2, PCI DSS a ISO 27001 – takže důkazy, které váš auditor potřebuje, pocházejí ze stejného zapojení, které chrání vaše API.
Shrnutí
Pokud je vaše webová aplikace tváří vašeho produktu, vaše API je jeho nervový systém. Jeho testování vyžaduje pochopení jak technické vrstvy protokolu, tak obchodní logiky, kterou implementuje. Penetrify poskytuje obojí – automatizované skenování pro široké pokrytí koncových bodů a manuální expertní testování pro chyby BOLA, autorizace a logiky, které definují skutečné riziko API.