API bezpečnost: Nejčastější zranitelnosti a jak je opravit

Počet API rozhraní ve firmách každoročně roste dvojciferným tempem. Mobilní aplikace, partnerské integrace, mikroslužby — všude API. A právě proto jsou API atraktivním cílem: útočník nepotřebuje překonávat firewall, stačí mu najít špatně zabezpečený endpoint. Podle dat z roku 2024 bylo více než 40 % bezpečnostních incidentů ve firmách spojeno právě se zranitelnostmi v API.

OWASP (Open Web Application Security Project) publikuje od roku 2019 speciální seznam API Security Top 10, který se liší od klasického OWASP Top 10 pro webové aplikace. V tomto článku projdeme nejzávažnější položky, vysvětlíme, proč jsou nebezpečné, a ukážeme, jak je opravit.

1. Broken Object Level Authorization (BOLA / IDOR)

BOLA je na prvním místě seznamu dlouhodobě a zaslouženě. Jde o situaci, kdy API neověřuje, zda má přihlášený uživatel skutečně přístup k objektu, který požaduje. Útočník změní ID v URL a získá cizí data.

Příklad z praxe: volání GET /api/orders/12345 vrátí objednávku číslo 12345. Pokud server neověří, zda patří přihlášenému uživateli, stačí postupně zkoušet čísla a stahovat cizí objednávky. Tato zranitelnost stála za úniky dat u mnoha e-shopů a fintech aplikací.

Jak BOLA opravit

• Každý přístup k objektu ověřujte vůči identitě volajícího — na straně serveru, nikoli klienta.
• Místo sekvenčních čísel používejte UUID nebo ULID, které jsou nepředvídatelné.
• Implementujte centralizovanou authorization vrstvu (např. OPA — Open Policy Agent).
• Logujte přístupy k citlivým objektům a monitorujte anomálie (neobvyklý počet různých ID z jednoho tokenu).

2. Excessive Data Exposure a Mass Assignment

Mnohé API vrací výrazně více dat, než klient potřebuje — spoléhají na to, že klient si relevantní pole vybere sám. To je špatný přístup. Útočník vidí veškerá data přenášená po síti a může využít interní pole (role, stav účtu, hash hesla), která nikdy neměla opustit backend.

Příbuznou zranitelností je Mass Assignment: klient pošle JSON s extra poli (například "isAdmin": true) a server je bez validace zapíše do databáze.

Jak problém řešit

• Definujte explicitní schéma odpovědi (DTO — Data Transfer Object) a vracejte pouze pole v něm uvedená.
• Nikdy neserializujte celý databázový model přímo do odpovědi.
• Pro příchozí data používejte allowlist povolených polí — vše ostatní ignorujte nebo odmítněte s chybou 400.
• Nástroje jako OpenAPI / Swagger vám pomohou schéma udržovat konzistentní.

3. Injection v API: SQL, NoSQL, Command Injection

Injection útoky jsou staré, ale v kontextu API nabývají nových podob. REST API přijímá vstupy v URL parametrech, query stringu, JSON těle i hlavičkách — a každý z těchto vstupů je potenciálním vektorem.

SQL injection přes API endpoint GET /api/products?category=shoes' OR '1'='1 může vrátit celý obsah databáze. NoSQL injection v MongoDB je specifická: útočníci využívají operátory jako $gt, $where nebo $regex vložené do JSON těla požadavku. Command injection hrozí všude, kde backend volá systémové příkazy na základě uživatelského vstupu.

Jak injection zranitelnosti eliminovat

• Vždy používejte parametrizované dotazy (prepared statements) — nikdy string concatenation.
• Validujte a sanitizujte všechny vstupy: typ, délku, povolené znaky.
• Pro NoSQL databáze zakažte nebo omezte nebezpečné operátory v uživatelském vstupu.
• Spouštějte backend s minimálními oprávněními (principle of least privilege).
• Implementujte WAF (Web Application Firewall) s pravidly pro detekci injection pokusů.

4. Autentizace, OAuth a správa API klíčů

Slabá autentizace je vstupní branou pro celou řadu dalších útoků. V oblasti API se nejčastěji setkáváme s těmito problémy:

Chyby v implementaci JWT

JSON Web Tokeny jsou rozšířené, ale jejich špatná implementace je zákeřná. Nejčastější chyby: použití algoritmu none (server akceptuje nepodepsané tokeny), slabý signing secret, příliš dlouhá expirace tokenů nebo absence blacklistingu odvolaných tokenů.

• Vždy explicitně specifikujte povolené algoritmy (HS256 nebo RS256) — nikdy nedůvěřujte hlavičce tokenu slepě.
• Expiraci nastavte na maximum 15–60 minut pro access tokeny, refresh tokeny ukládejte bezpečně.
• Implementujte token revocation (blacklist nebo short-lived tokeny s refresh mechanismem).

OAuth 2.0 v praxi

OAuth 2.0 je standard pro delegovanou autorizaci, ale jeho špatná implementace je velmi častá. Kritické požadavky: vždy validujte redirect_uri přesnou shodou (ne prefixem), používejte PKCE pro public clients, stav (state parametr) chraňte před CSRF.

API klíče

• API klíče nikdy neposílejte v URL (jsou v access logu) — vždy v hlavičce Authorization nebo X-API-Key.
• Implementujte rotaci klíčů a možnost okamžitého odvolání.
• Klíče s různými oprávněními (read-only vs. read-write) — princip nejmenších oprávnění.
• Detekujte kompromitované klíče v GitHub repozitářích pomocí nástrojů jako GitHub Secret Scanning nebo GitLeaks.

5. Rate Limiting a ochrana před zneužitím

API bez rate limitingu je jako dveře bez zámku. Útočník může provádět credential stuffing (testování ukradených přihlašovacích údajů), scraping dat, brute force na hesla nebo způsobit DoS zahlcením serveru.

Rate limiting nestačí implementovat pouze na úrovni IP adresy — sofistikovaní útočníci distribuují provoz přes botnet s tisíci IP adresami. Efektivní ochrana vyžaduje kombinaci více přístupů:

• Per-user rate limiting: omezení na základě autentizovaného uživatele nebo API klíče.
• Per-endpoint rate limiting: citlivé endpointy (login, reset hesla, platby) mají přísnější limity než ostatní.
• Sliding window algoritmus: spravedlivější než fixed window, zabraňuje burst útokům na hranici okna.
• Exponential backoff: po opakovaných chybách se čekací doba prodlužuje.
• CAPTCHA pro veřejné endpointy při detekci podezřelého chování.

Nezapomeňte vracet správné HTTP kódy: 429 Too Many Requests s hlavičkou Retry-After. V odpovědi sdělte limit, ale ne tak, aby útočník snadno kalibroval svůj útok.

Jak správně testovat bezpečnost API

Znalost zranitelností je polovina úspěchu — druhá polovina je schopnost je najít dříve než útočník. Bezpečnostní testování API by mělo být součástí vývojového procesu (shift-left security), ne jednorázovou aktivitou před nasazením.

Nástroje pro testování API

• OWASP ZAP: open-source scanner s podporou REST API, GraphQL i SOAP. Vhodný pro automatizované testy v CI/CD pipeline.
• Burp Suite: profesionální nástroj pro manuální testování, zachytávání a modifikaci požadavků.
• Postman + Newman: psaní a automatizace bezpečnostních testů v rámci kolekce API testů.
• Nuclei: šablonovací engine pro rychlé skenování known vulnerabilities.
• 42Crunch: specializovaný nástroj pro audit OpenAPI specifikací.

Metodika testování

1. Začněte inventarizací všech API endpointů — zjistíte překvapení (zapomenuté, neudržované endpointy).
2. Ověřte autorizaci na každém endpointu: přihlaste se jako uživatel A a zkuste přistupovat k datům uživatele B.
3. Testujte boundary hodnoty a nevalidní vstupy — sledujte, zda server vrací detailní chybové zprávy (information disclosure).
4. Zkontrolujte HTTP metody: endpoint, který má podporovat jen GET, by neměl akceptovat PUT nebo DELETE.
5. Prověřte bezpečnostní hlavičky odpovědí: Content-Security-Policy, X-Content-Type-Options, Strict-Transport-Security.

Profesionální penetrační testování API od SecureOn.cz zahrnuje kompletní pokrytí OWASP API Security Top 10, manuální testování logiky aplikace a detailní report s prioritizovanými nálezy a doporučeními pro nápravu. Kontaktujte nás pro nezávaznou konzultaci.

Závěr: API bezpečnost jako kontinuální proces

Zabezpečení API není jednorázový projekt — je to kontinuální proces zahrnující bezpečný návrh, code review, automatizované testování v CI/CD a pravidelné penetrační testy. Nejnebezpečnější jsou zranitelnosti, které nevyžadují technickou sofistikovanost útočníka: BOLA a excessive data exposure může zneužít kdokoli s browserem a základními znalostmi HTTP.

Zavedením OWASP API Security Top 10 jako checklistu do vašeho procesu vývoje, implementací správné autentizace a autorizace, rate limitingem a pravidelným testováním výrazně snížíte pravděpodobnost úspěšného útoku. Investice do API bezpečnosti je vždy levnější než řešení úniku dat.