Jak chránit API před DDoS útoky.

API je DDoS cíl s odstraněnou obranou

Většina mitigace na aplikační vrstvě se opírá o jeden praktický fakt: skuteční návštěvníci webu přicházejí v prohlížeči. Lehká výzva požádá klienta, aby spustil trochu JavaScriptu a vrátil podepsanou cookie — a co to nedokáže, nikdy nebyl zákazník.

API takový signál nemá. curl, SDK, mobilní aplikace, CI pipeline i platební webhook jsou všechno legitimní klienti a ani jeden z nich neumí projít prohlížečovou výzvou nebo si uchovat cookie. Nasměrujte na /api/ ochranu šitou na prohlížeče a dostanete to nejhorší z obou světů: poctivé integrace se rozbijí ve chvíli, kdy ochrana přitvrdí, zatímco útočník, který přesměrování prostě ignoruje, endpoint dál buší.

V tom je celý problém. Mitigace API se nemůže ptát „je to člověk?" — musí se ptát „je tento klient identifikovaný a drží se ve svém rozpočtu?"

Co se mezi webem a API mění

Jak DDoS útoky na API skutečně vypadají

• Ploché záplavy endpointu — tisíce požadavků za sekundu na jednu cestu, rozprostřené přes rotující adresy, tempem, jaké by skutečný klient nikdy neudělal.
• Zneužití drahých dotazů — hluboké stránkování (?page=48000), neomezený limit, široké časové rozsahy nebo řazení podle všeho, které z jednoho požadavku udělají průchod celou tabulkou.
• Bomby v GraphQL dotazech — jediný syntakticky validní dotaz s vnořenými relacemi, který se rozvine do tisíců volání resolverů. Drobný požadavek, obrovská cena.
• Zkoušení tokenů a credential stuffing — automatizované pokusy na /auth/login nebo /oauth/token s uniklými seznamy hesel. Zároveň pokus o převzetí účtů a záplava na váš nejdražší endpoint.
• Záplavy webhooků a callbacků — vaše veřejná callback URL je z definice zdokumentovaná a přehrání odposlechnutých payloadů je triviální, pokud neověřujete podpisy.
• Parametry na obejití cache — náhodné query stringy sestavené tak, aby každý požadavek minul cache a dopadl na origin.
• Nechtěný self-DDoS — jeden klient nasadí smyčku opakování bez backoffu. Není to zlý úmysl, od útoku se to nedá rozeznat a náprava je stejná.

Společným jmenovatelem je asymetrie nákladů za každým útokem na vrstvě 7: útočník zaplatí jeden levný HTTP požadavek, vy zaplatíte časem databáze. Endpointy API přímo odpovídají drahým operacím, což je dělá nejvýhodnějším cílem ve vaší infrastruktuře.

Krok 1 — Nejdřív klienta identifikujte, potom omezujte

Rate limit je jen tak dobrý jako klíč, podle kterého počítá — a IP adresa je zároveň výchozí i nejslabší volba: botnet má tisíce adres, zatímco firemní NAT nebo mobilní operátor schová za jednu adresu tisíce vašich skutečných uživatelů.

Preferujte v tomto pořadí:

1. Přihlašovací údaj — API klíč, bearer token nebo ID účtu. Před použitím jako klíč limitu ho zahašujte, aby se nikde neukládal v původní podobě.
2. Ověřený podpis webhooku — zkontrolujte podpis a omezujte odesílatele, ne adresu, ze které přišel.
3. IP adresu — záložní volba pro skutečně anonymní endpointy a dobrý důvod držet je levné.

Vyžadovat klíč na každé neveřejné cestě je ta nejhodnotnější změna, kterou můžete udělat. Změní anonymní záplavu na identifikovaného klienta překračujícího zdokumentovaný rozpočet — problém s jasným a automatizovatelným řešením.

Krok 2 — Nastavte limity tak, aby je stroje dokázaly respektovat

• Token bucket na klienta, aby legitimní špička prošla a trvalá záplava ne. Ke skutečnému používání SDK je mnohem přátelštější než fixní okno, které se resetuje na sekundu.
• Strop pro celou zónu nad limity jednotlivých klientů, aby deset tisíc čerstvě registrovaných klíčů nemohlo každý „po právu" a přesto vás dohromady položit.
• Oddělené rozpočty podle cenové třídy. GET /v1/status a POST /v1/reports nepatří pod stejný limit.
• Odpovídejte kódem 429 a hlavičkou Retry-After, ideálně i RateLimit-Limit a RateLimit-Remaining. Slušně napsaný klient sám zpomalí; odpověď, kterou nedokáže přečíst, změní vaši mitigaci ve výpadek.
• Nikdy na cestu API neposílejte výzvu, CAPTCHU ani 302. Strojový klient to vyhodnotí jako poškozenou odpověď, opakuje pokus tvrději a přidá se k záplavě, kterou jste chtěli zastavit.

Krok 3 — Zlevněte obsluhu jednoho požadavku

Rate limity omezují, kolik požadavků přijde. Stropy ceny omezují, kolik škody každý z nich udělá.

• Omezte limit a per_page, odmítejte neomezené rozsahy a používejte kurzorové stránkování, aby hluboké offsety přestaly být drahé.
• Vynucujte limity hloubky a složitosti GraphQL dotazů a v produkci vypněte introspekci.
• Nastavte tvrdé timeouty na databázové dotazy a volání nadřazených služeb, aby jedna pomalá cesta nenahromadila spojení, dokud nevyčerpá pool.
• Cachujte, co se cachovat dá — veřejné GETy, referenční data, spočítané agregace — s krátkými TTL na edge. Každý zásah cache je požadavek, který origin nikdy neobslouží, a proto je CDN pancířem i pro API.
• Skutečně drahou práci přesuňte do fronty a vraťte 202 s URL úlohy, aby ze špičky byla čekající fronta, ne výpadek.

Krok 4 — Zaveďte to, aniž byste rozbili klienty

1. Nejdřív měřte. Vytáhněte z logů p95 a p99 tempo požadavků na klienta. Skutečné limity vycházejí ze skutečných percentilů, ne z okrouhlých čísel.
2. Spusťte režim jen log na týden či dva a sledujte, kdo by byl omezen. Bývá to jedna integrace s rozbitou smyčkou opakování, ne útok.
3. Nastavte limit nad svého nejhlasitějšího poctivého klienta a pak ho vynuťte.
4. Zdokumentujte limity i kontrakt 429 v referenci svého API, aby to integrátoři ošetřili dřív, než na limit narazí.
5. Alertujte na dosažené limity, ne až na výpadek. Klient překračující rozpočet je to nejranější varování, které dostanete.

Krok 5 — Uzamkněte origin

Nic z výše uvedeného nepomůže, pokud se k vašemu API dá dostat přímo. Útočníci dohledají historii DNS daného hostu, najdou adresu serveru a filtrační edge zcela obejdou. Nastavte firewall originu tak, aby přijímal provoz jen z vaší ochranné sítě, a zavřete běžné úniky — neproxované subdomény, mailové záznamy, logy transparentnosti certifikátů. Celý postup najdete v článku jak skrýt IP adresu originu.

Jak Itnetic chrání cesty API

Naší výchozí obranou je prohlížečová výzva, což je pro strojový provoz přesně špatný nástroj — cesty API proto mají vlastní pipeline. Prefixy cest jako /api/ nebo /graphql označíte jako API zónu a odpovídající požadavky se od začátku do konce berou jako strojový provoz: nikdy nedostanou výzvu ani tag cookies a nikdy je nepočítají detektory záplav zaměřené na prohlížeče, které by jinak SDK bez cookies vyhodnotily jako útočníka.

Ochrana uvnitř zóny je přesně to, co tento článek doporučuje. Limity token-bucket na klienta klíčované podle hlavičky, kterou si vyberete — obvykle Authorization, zahašovaná, takže se původní údaj nikde neukládá — s fallbackem na IP pro anonymní cesty, plus strop pro záplavu v celé zóně, který nastartuje krátké okno útoku. Omezený klient dostane 429 s Retry-After, nikdy HTML. Pro okno útoku si zvolíte přístup: blokovat označené signatury útočníků, navíc odmítat požadavky bez vaší klíčové hlavičky, nebo jen logovat, dokud ladíte. Neplatná konfigurace zóny se bezpečně vrátí k běžné webové pipeline, takže špatné pravidlo vám API nikdy nepoloží.

Každý verdikt skončí v logu jednotlivých požadavků spolu s fingerprintem klienta a pravidlem, které se uplatnilo — přesně to potřebujete, když se integrátor ptá, proč jeho noční úloha začala dostávat 429. Útočný provoz se nikdy nepočítá do vašeho limitu přenosu, takže z útoku nevznikne faktura; viz ceník.

DDoS ochrana od Itnetic pokrývá weby i API na téže edge síti a zapíná se dvěma DNS záznamy. Pokud chcete nejdřív kontext, začněte tím, co je DDoS mitigace.