Zpět na blog
29. dubna 2026

Jak zabezpečit vaše koncové body API proti útokům BOLA

Vytvořili jste elegantní API. Je rychlé, škálovatelné a zajišťuje skvělou uživatelskou zkušenost. Pravděpodobně jste si odškrtli základy: máte povolené HTTPS, používáte JWT nebo API klíče pro autentizaci a možná jste dokonce spustili skener zranitelností. Cítíte se bezpečně. Existuje však tichý zabiják ve světě zabezpečení API, kterého tradiční skenery často přehlížejí, a nevyžaduje složité zneužití ani sofistikovaný datový balíček, aby fungoval.

Nazývá se BOLA—Narušená autorizace na úrovni objektů.

Pokud nejste s tímto pojmem obeznámeni, BOLA je v podstatě trik se "záměnou ID". Představte si, že se uživatel přihlásí do vaší aplikace a uvidí svůj profil na api.example.com/user/12345. Všimne si čísla na konci. Z rozmaru změní 12345 na 12346. Pokud váš server ochotně vrátí soukromá data uživatele 12346, aniž by zkontroloval, zda má žadatel skutečně oprávnění je vidět, máte zranitelnost BOLA.

Zní to jednoduše – až příliš jednoduše. Ale tato jednoduchost je důvodem, proč je BOLA trvale hodnocena jako hrozba č. 1 v žebříčku OWASP API Security Top 10. Proč? Protože se nejedná o selhání autentizace (vědět, kdo je uživatel), ale o selhání autorizace (vědět, co uživatel smí dělat).

Zabezpečení vašich API koncových bodů proti útokům BOLA není o přidání většího firewallu; jde o změnu způsobu, jakým vaše aplikace nakládá s vlastnictvím dat. V tomto průvodci podrobně rozebereme, jak přesně BOLA funguje, proč k ní dochází a jaké konkrétní kroky můžete podniknout k trvalému zabezpečení vašich koncových bodů.

Co přesně je BOLA a proč je tak nebezpečná?

Abychom pochopili BOLA, musíme rozlišovat mezi autentizací a autorizací. Tyto dva pojmy se často zaměňují, ale v kontextu zabezpečení API jsou to světy od sebe.

Autentizace je proces ověřování identity uživatele. "Jste ten, za koho se vydáváte?" Když uživatel zadá heslo nebo token a váš systém řekne "Ano", je autentizován.

Autorizace je proces ověřování oprávnění. "Teď, když vím, kdo jste, smíte přistupovat k tomuto konkrétnímu kusu dat?"

K BOLA dochází, když aplikace poskytuje přístup k objektu (záznam v databázi, soubor, uživatelský účet) na základě vstupu poskytnutého uživatelem, ale nedokáže ověřit, zda autentizovaný uživatel skutečně vlastní nebo má oprávnění k přístupu k tomuto objektu.

Anatomie útoku BOLA

Typický útok BOLA se řídí velmi předvídatelným vzorem:

  1. Pozorování: Útočník si vytvoří legitimní účet na vaší platformě. Začne používat aplikaci a všimne si, že požadavky API používají předvídatelné identifikátory (například celá čísla) v URL adrese.
  2. Manipulace: Útočník použije proxy nástroj (jako Burp Suite nebo Postman) k zachycení požadavku. Uvidí požadavek jako GET /api/v1/orders/9876.
  3. Iterace: Útočník změní 9876 na 9875, 9874 a tak dále.
  4. Exfiltrace: Pokud server nezkontroluje vlastnictví objednávky 9875, vrátí data. Útočník pak napíše jednoduchý skript, který projde tisíce ID a během několika minut vysaje celou vaši databázi.

Proč tradiční bezpečnostní nástroje nedokážou odhalit BOLA

Pokud používáte standardní Web Application Firewall (WAF) nebo základní skener zranitelností, možná se ptáte, proč vás na to neupozornily.

Problém je, že útoky BOLA vypadají jako naprosto legitimní provoz. Pro WAF vypadá požadavek na /api/v1/orders/9875 identicky jako požadavek na /api/v1/orders/9876. Oba jsou platné HTTP GET požadavky. Oba mají platný autentizační token. „Útok“ se odehrává v obchodní logice vašeho kódu, nikoli ve formátování požadavku.

Zde se projevuje rozdíl mezi „skenováním“ a „testováním“. Skener hledá známé signatury (například řetězce SQL Injection); Penetration Test hledá logické chyby. Proto se týmy přesouvají k Continuous Threat Exposure Management (CTEM) a používají platformy jako Penetrify. Potřebujete systém, který rozumí kontextu vašich API volání, nejen tomu, zda je požadavek „dobře formátovaný“.

Běžné scénáře, kde se BOLA proplíží dovnitř

BOLA se neomezuje pouze na jeden typ koncového bodu. Objevuje se všude tam, kde se k načítání dat používá unikátní ID. Zde jsou některá z nejčastějších míst, kde se skrývá.

Uživatelské profily a nastavení účtu

Toto je klasický příklad. Koncové body jako /api/users/{userId}/settings nebo /api/me/profile jsou hlavními cíli. Pokud backend jednoduše vezme {userId} z URL a dotazuje se databáze, aniž by zkontroloval, zda current_user.id == requested_userId, může jakýkoli přihlášený uživatel prohlížet nebo upravovat nastavení jakéhokoli jiného uživatele.

E-commerce a historie objednávek

Představte si stránku „Moje objednávky“. API může volat /api/orders/{orderId}. Útočník může jednoduše inkrementovat orderId, aby viděl nákupy, adresy a telefonní čísla jiných lidí. To je zlatý důl pro zloděje identit.

Izolace tenantů v SaaS

Pro společnosti vyvíjející multi-tenant SaaS aplikace může být BOLA katastrofální. Pokud máte strukturu jako /api/tenant/{tenantId}/projects a uživatel z Tenanta A může přistupovat k projektům Tenanta B pouhou změnou tenantId, máte masivní únik dat. To není jen chyba; je to zásadní selhání izolace tenantů.

Nahrávání a stahování souborů

Mnoho aplikací ukládá soubory (faktury, ID, fotografie) a poskytuje je prostřednictvím koncových bodů jako /api/files/download?fileId=5542. Pokud systém nekontroluje, zda má uživatel oprávnění k přístupu k fileId 5542, může útočník získat každý dokument nahraný na vaši platformu.

Podrobný průvodce implementací obrany proti BOLA

Jak to tedy vlastně zastavíte? Vyžaduje to vrstvený přístup. Nemůžete se spoléhat na jedno „zázračné“ řešení. Místo toho musíte autorizaci vnést do samotné podstaty vašeho API designu.

1. Implementujte přísné kontroly autorizace na úrovni objektů

Nejpřímější způsob, jak zastavit BOLA, je ověřit vlastnictví u každého jednotlivého požadavku, který přistupuje k prostředku.

Špatný způsob (pseudo-kód):

app.get('/api/orders/:orderId', async (req, res) => {
  const order = await db.Orders.findOne({ id: req.params.orderId });
  res.json(order); 
  // NEBEZPEČÍ: Nekontroluje se, zda objednávka patří uživateli!
});

Správný způsob (pseudo-kód):

app.get('/api/orders/:orderId', async (req, res) => {
  const userId = req.user.id; // Get ID from the authenticated JWT
  const orderId = req.params.orderId;

  const order = await db.Orders.findOne({
    where: {
      id: orderId,
      userId: userId // MUST filter by the owner's ID
    }
  });

  if (!order) {
    return res.status(404).send('Order not found');
    // Use 404 instead of 403 to avoid leaking that the ID exists
  }
  res.json(order);
});

Zahrnutím userId přímo do databázového dotazu zajistíte, že databáze vrátí záznam pouze tehdy, pokud patří osobě, která o něj žádá. Pokud ID existuje, ale nepatří uživateli, dotaz vrátí null a vy odešlete 404.

2. Nahraďte předvídatelná ID identifikátory UUID

Používání sekvenčních celých čísel (1, 2, 3...) pro vaše primární klíče je pro útočníky darem. Zjednodušuje to "procházení ID" (ID walking) nebo "enumeraci".

Zatímco používání UUID (Universally Unique Identifiers) neopravuje základní chybu autorizace, útočníkovi téměř znemožňuje uhodnout platné ID.

  • Sekvenční ID: 1001 $\rightarrow$ další je 1002.
  • UUID: 550e8400-e29b-41d4-a716-446655440000.

Přechod na UUID zvyšuje "náklady" útoku. Útočník nemůže jednoduše napsat for smyčku od 1 do 10 000. Nejprve by musel nějak najít platné UUID. Nicméně pamatujte: UUID jsou obfuskace, nikoli zabezpečení. Pokud útočník najde UUID v uniklém logu nebo v jiné odpovědi API, stále může zneužít zranitelnost BOLA, pokud chybí vaše autorizační kontroly.

3. Použijte centralizovaný autorizační middleware

Psaní autorizační logiky uvnitř každého jednotlivého kontroleru je receptem na katastrofu. Určitě na jeden zapomenete. Určitě přehlédnete okrajový případ.

Místo toho přesuňte svou autorizační logiku do middleware nebo vyhrazené služby. Tím zajistíte konzistentní politiku napříč celým API. Můžete implementovat systém řízení přístupu založený na politikách, kde definujete, kdo může provádět jakou akci na jakém zdroji.

Například middleware by mohl zkontrolovat: canUserAccessResource(user, resourceType, resourceId, action)

Pokud pracujete ve složitém prostředí s více poskytovateli cloudu (AWS, Azure, GCP), správa těchto oprávnění může být chaotická. Zde se stává klíčovou automatizovaná bezpečnostní orchestrace. Nástroje jako Penetrify vám pomohou zmapovat vaši útočnou plochu a simulovat tyto typy útoků "výměny ID" napříč vašimi prostředími, abyste našli mezery, které vaši vývojáři mohli přehlédnout.

4. Implementujte Rate Limiting a detekci anomálií

Útok BOLA obvykle zahrnuje vysoký objem požadavků v krátkém časovém úseku, kdy se útočník snaží získat data. Zatímco Rate Limiting nezastaví jeden cílený BOLA požadavek, zastaví pokus o hromadnou exfiltraci dat.

  • Rate Limiting na uživatele: Omezte počet požadavků, které může jeden ověřený uživatel provést na citlivé koncové body.
  • Monitorování 404: Pokud jeden uživatel vyvolá 500 chyb "Not Found" během jedné minuty na koncovém bodě jako /api/orders/{id}, téměř jistě hledá platná ID. Spusťte upozornění nebo dočasně zablokujte IP/účet.

BOLA v různých architekturách API: GraphQL a REST

Způsob, jakým bojujete proti BOLA, mírně závisí na tom, jak je vaše API strukturováno.

BOLA v REST API

V REST API se BOLA obvykle vyskytuje v cestě URL (jak jsme probrali). Řešení je přímočaré: vždy ověřte, že userId extrahované ze session/tokenu má vztah k resourceId v URL.

BOLA v GraphQL

GraphQL je o něco záludnější, protože používá jediný koncový bod (obvykle /graphql) a dotazovací jazyk. Útočníci nemění URL; mění argumenty v rámci dotazu.

Příklad GraphQL dotazu:

query {
  user(id: "12345") {
    email
    phoneNumber
    creditCardLastFour
  }
}

Útočník jednoduše změní argument id. Protože GraphQL často zahrnuje „vnořování“ (načítání uživatele, poté jeho objednávek, poté podrobností o doručení těchto objednávek), jediná zranitelnost BOLA v jednom resolveru může vést k masivní kaskádě úniku dat.

Řešení pro GraphQL: Autorizace musí probíhat na úrovni resolveru. Každý resolver, který načítá objekt z databáze, musí provést stejnou kontrolu vlastnictví, jakou jsme probrali pro REST API. Nepředpokládejte, že pokud byl autorizován dotaz nejvyšší úrovně, jsou autorizovány i vnořené objekty.

Porovnání manuálního Penetration Testingu vs. automatické detekce BOLA

Pokud je BOLA tak nebezpečná, proč si jednoduše nenajmout firmu na Penetration Testing jednou ročně? Zde je realita modelu „jednou ročně“.

Funkce Tradiční manuální Penetration Test Kontinuální automatizované testování (např. Penetrify)
Frekvence Roční nebo pololetní Na vyžádání / Kontinuální
Náklady Vysoké (poplatky butikových firem) Na bázi předplatného / Škálovatelné
Pokrytí Hluboké, ale snímek v čase Široké a vyvíjí se se změnami kódu
Zpětná vazba Týdny po testu V reálném čase nebo téměř v reálném čase
Integrace CI/CD Žádná (manuální předání) Integrováno do DevSecOps

Manuální testeři jsou skvělí v hledání složitých logických chyb, ale nemohou být přítomni pokaždé, když vaši vývojáři odešlou nový commit do produkce. Pokud vývojář v úterý přidá nový koncový bod /api/v1/user-preferences a váš poslední Penetration Test byl v lednu, je tento koncový bod otevřenými dveřmi pro BOLA až do příštího ledna.

Proto prosazujeme Penetration Testing as a Service (PTaaS). Automatizací fází průzkumu a skenování se můžete posunout směrem ke Continuous Threat Exposure Management (CTEM). Neskenujete jen „chyby“; simulujete chování útočníka, který se snaží manipulovat s ID objektů.

Pokročilé strategie pro vysoce zabezpečená prostředí

Pro ty z vás, kteří nakládají s vysoce citlivými daty (zdravotní záznamy, finanční transakce, vládní data), „dostatečně dobré“ nestačí. Potřebujete strategii obrany do hloubky.

1. Používejte nepřímé reference na objekty (založené na mapování)

Pokud absolutně nemůžete důvěřovat klientovi s jakoukoli verzí ID databáze, použijte mapu specifickou pro session.

Namísto vystavení order_id: 9876 uživateli váš server pro danou session vygeneruje náhodný dočasný klíč:

  • TemporaryKey_A $\rightarrow$ order_id: 9876
  • TemporaryKey_B $\rightarrow$ order_id: 9877

Klient vždy vidí pouze TemporaryKey_A. Pokud se pokusí uhodnout TemporaryKey_C, neexistuje v jejich mapě relací a požadavek selže. Tím se zcela eliminuje předvídatelnost ID.

2. Řízení přístupu na základě atributů (ABAC)

Jak vaše organizace roste, řízení přístupu na základě rolí (RBAC) jako „Admin“ nebo „User“ se stává příliš hrubým. Potřebujete ABAC.

ABAC vám umožňuje definovat zásady na základě atributů:

  • Atribut uživatele: ClearanceLevel: Level 2
  • Atribut zdroje: Sensitivity: Level 2
  • Atribut prostředí: AccessTime: 9am-5pm

Kontrola BOLA v systému ABAC by vypadala takto: „Může tento uživatel přistupovat k tomuto objektu, pokud se oddělení uživatele shoduje s oddělením objektu A objekt není označen jako ‚Private‘?“ To poskytuje mnohem detailnější úroveň zabezpečení.

3. Digitální podpisy pro ID

Některé vysoce zabezpečené API podepisují svá ID. Když server odešle ID klientovi, připojí kryptografický podpis (HMAC). Když klient odešle ID zpět, server podpis ověří. Pokud uživatel změní 123 na 124, podpis se stane neplatným a server požadavek okamžitě odmítne – ještě předtím, než se dostane do databáze.

Časté chyby při pokusu o opravu BOLA

Tyto chyby dělají i zkušení vývojáři. Pokud provádíte audit svého kódu, hledejte tyto vzory.

Chyba 1: Spoléhání se na frontend při skrývání tlačítek

„Uživatel nemůže přistupovat na stránku ‚Edit‘, protože jsem skryl tlačítko v uživatelském rozhraní React.“ Toto je zabezpečení založené na nejasnosti. Útočník nepoužívá vaše uživatelské rozhraní; používá terminál nebo proxy. Vždy předpokládejte, že útočník zná každý jednotlivý API koncový bod, který máte.

Chyba 2: Kontrola autorizace pouze na vstupním bodě

Vývojáři často kontrolují, zda je uživatel přihlášen na začátku požadavku, a poté předpokládají, že vše uvnitř tohoto požadavku je bezpečné.

  • Špatně: if (!user.isAuthenticated) return 401; $\rightarrow$ pokračovat v načítání libovolného ID.
  • Správně: if (!user.isAuthenticated) return 401; $\rightarrow$ if (!user.owns(resourceId)) return 404;.

Chyba 3: Únik platných ID v jiných koncových bodech

Možná jste opravili BOLA na svém /api/orders koncovém bodě, ale máte /api/search/users koncový bod, který vrací seznam všech ID uživatelů? Pokud ano, právě jste útočníkovi dali mapu, kterou potřebuje k útoku na vaše další koncové body. Vždy minimalizujte množství dat ID, která vystavujete v zobrazeních „seznamu“ nebo „vyhledávání“.

Chyba 4: Použití 403 Forbidden namísto 404 Not Found

Když uživatel požaduje objekt, který nevlastní, vrácení 403 Forbidden útočníkovi říká: „Tento objekt existuje, ale nemáte oprávnění ho vidět.“ Vrácením 404 Not Found útočníkovi říkáte: „Nemám tušení, o čem mluvíte.“ To zabraňuje útočníkovi potvrdit, zda je konkrétní ID platné, či nikoli.

Kontrolní seznam „BOLA Audit“ pro váš tým

Pokud vedete tým DevOps nebo bezpečnostní tým, můžete tento kontrolní seznam použít během vaší příští sprint review nebo bezpečnostního auditu.

  • Inventář: Máme kompletní seznam všech API endpointů, které přijímají ID jako parametr?
  • Identita: Extrahujeme ID uživatele z bezpečného tokenu na straně serveru (například JWT), namísto abychom důvěřovali ID uživatele zaslanému v těle požadavku nebo URL?
  • Vlastnictví: Obsahuje každý databázový dotaz na konkrétní zdroj filtr pro ID vlastnícího uživatele nebo ID nájemce?
  • Předvídatelnost: Používáme UUID nebo jiné nesekvenční identifikátory pro veřejně dostupné zdroje?
  • Konzistence: Je autorizace řešena v centralizovaném middleware nebo službě, namísto aby byla duplikována v každém kontroleru?
  • Zpracování chyb: Vracíme 404 namísto 403 pro neautorizovaný přístup k objektu?
  • Omezení rychlosti: Máme upozornění pro uživatele, kteří vyvolají neobvyklý počet 404 na resource endpointech?
  • Testování: Provádíme automatizované testy "ID swap" jako součást našeho CI/CD pipeline?

Jak Penetrify zjednodušuje detekci BOLA

Ruční hledání BOLA zranitelností je únavné. Musíte zmapovat každý endpoint, vytvořit více uživatelských účtů a ručně otestovat každou kombinaci ID. Pro malý tým je to nemožný úkol. Pro velký tým je to úzké hrdlo.

Přesně proto byl Penetrify vytvořen. Namísto spoléhání se na statické skenování, které hledá "zastaralé knihovny", se Penetrify zaměřuje na útočnou plochu.

Zde je, jak vám pomůže vyřešit problém BOLA:

  1. Automatizované mapování útočné plochy: Penetrify identifikuje všechny vaše exponované endpointy, včetně těch, které vaši vývojáři možná zapomněli zdokumentovat.
  2. Inteligentní simulace logiky: Platforma neposílá jen náhodné řetězce; analyzuje, jak jsou strukturována vaše ID, a pokouší se simulovat chování "ID walking", které používají manuální pentesters.
  3. Nepřetržité monitorování: Protože je cloud-native, Penetrify lze integrovat do vašeho DevSecOps workflow. Pokaždé, když nasadíte novou verzi vašeho API, přehodnotí váš bezpečnostní perimetr.
  4. Akční náprava: Nezískate jen zprávu s textem "Máte BOLA chybu." Získáte konkrétní pokyny, který endpoint je zranitelný a jak implementovat kontrolu autorizace k jeho opravě.

Překlenutím mezery mezi jednoduchým skenerem zranitelností a drahou manuální auditací umožňuje Penetrify malým a středním podnikům (SME) a SaaS startupům prokázat svou bezpečnostní zralost (pro SOC2 nebo HIPAA compliance), aniž by potřebovaly plnohodnotný interní Red Team.

Často kladené otázky (FAQ)

Otázka: Nemohu prostě použít WAF k zastavení BOLA?

Ne efektivně. Jak již bylo zmíněno, BOLA útoky používají platnou syntaxi a platnou autentizaci. WAF se dívá na strukturu požadavku, zatímco BOLA je selháním obchodní logiky. Zatímco WAF může pomoci s omezením rychlosti (rate limiting) k zpomalení útočníka, nemůže určit, zda by Uživatel A měl mít přístup k Objednávce B.

Otázka: Zabraňuje použití JWT (JSON Web Tokens) BOLA?

Ne. JWTs se starají o autentizaci (prokázání, kdo je uživatel). Nestarají se o autorizaci (k čemu má uživatel přístup). Uživatel může mít dokonale platný, podepsaný JWT a přesto jej použít k vyžádání objektu, který mu nepatří, pokud váš backend neprovádí kontrolu vlastnictví.

Otázka: Pokud používám NoSQL databázi jako MongoDB, jsem stále v ohrožení?

Ano. BOLA je nezávislá na typu databáze. Ať už používáte _id v MongoDB (která jsou přirozeně složitější než celá čísla) nebo sekvenci v PostgreSQL, zranitelnost existuje, pokud aplikace umožňuje uživateli vyžádat si záznam podle ID bez ověření vlastnictví.

Otázka: Je BOLA to samé jako IDOR?

V podstatě ano. IDOR (Insecure Direct Object Reference) je starší, širší termín. BOLA je moderní terminologie speciálně přizpůsobená pro API. V kontextu API je útok BOLA formou IDOR.

Otázka: Jak otestuji BOLA, aniž bych kupoval drahý nástroj?

Můžete začít použitím proxy, jako je Burp Suite (Community Edition). Vytvořte dva samostatné uživatelské účty. Přihlaste se jako Uživatel A, zachyťte požadavek na zdroj, který vlastníte, a poté nahraďte ID zdroje ID, které patří Uživateli B. Pokud vidíte data Uživatele B, zatímco jste přihlášeni jako Uživatel A, máte zranitelnost BOLA.

Závěrečné myšlenky: Posun za jednorázové zabezpečení

Největší chybou, kterou může společnost udělat v zabezpečení API, je věřit, že jediná „čistá“ zpráva z Penetration Testu znamená, že jsou v bezpečí. Zabezpečení není cíl; je to stav neustálé údržby.

Váš kód se mění každý den. Vaše infrastruktura se škáluje. Nové endpointy jsou přidávány, aby uspokojily požadavek klienta. Každá z těchto změn je příležitostí pro proklouznutí zranitelnosti BOLA.

Přechod od „jednou ročních auditů“ k „Continuous Threat Exposure Management“ je jediný způsob, jak zůstat napřed před moderními útočníky. Kombinací přísné autorizační logiky, nepředvídatelných ID a automatizovaných testovacích platforem, jako je Penetrify, můžete přestat vnímat zabezpečení jako pouhou „fajfku“ a začít ho považovat za klíčovou funkci vašeho produktu.

Nečekejte na únik dat, abyste zjistili, že vaše autorizační logika je chybná. Začněte auditovat své endpointy ještě dnes, implementujte kontroly vlastnictví, o kterých jsme hovořili, a automatizujte své testování, abyste se mohli soustředit na vývoj svého produktu namísto obav z dalšího útoku „ID swap“.

Jste připraveni zjistit, zda jsou vaše API skutečně zabezpečená? Přestaňte hádat a začněte testovat. Navštivte Penetrify a zjistěte, jak automatizované, on-demand bezpečnostní testování může ochránit vaše data a vaši reputaci.

Zpět na blog