Rate Limiting

Rate limiting (ograniczanie tempa żądań) to mechanizm, który pilnuje, ile zapytań jeden klient może wysłać do serwera, API lub usługi w danym czasie. Gdy klient przekroczy ustalony limit, kolejne zapytania zostają odrzucone — zwykle z kodem HTTP 429 Too Many Requests (czyli „zbyt wiele żądań”) — albo celowo opóźnione. Dzięki temu usługa zostaje dostępna dla wszystkich, zasoby dzielą się sprawiedliwie, a wiele nadużyć (ataki DDoS, łamanie haseł, masowe logowania wykradzionymi danymi, scraping) staje się trudniejszych.

Jak działa rate limiting?

Rate limiter opiera się na trzech rzeczach. Pierwsza to klucz, który mówi, kto wysyła zapytanie — może nim być adres IP, klucz API, identyfikator użytkownika lub sesji. Druga to limit, czyli ile zapytań wolno wysłać. Trzecia to okno czasowe, czyli w jakim przedziale ten limit obowiązuje (np. 100 zapytań na minutę). Dla każdego klucza system zlicza zapytania w bieżącym oknie i porównuje wynik z limitem. Gdy pula się wyczerpie, następne zapytania są blokowane lub ustawiane w kolejce, dopóki okno się nie odnowi.

Wybór klucza ma znaczenie. Limit po samym adresie IP jest prosty, ale zawodzi w dwóch sytuacjach. Po pierwsze, gdy wielu użytkowników dzieli jeden adres — tak działa NAT, proxy czy CGNAT, czyli mechanizmy, które chowają wiele urządzeń za jednym adresem. Po drugie, gdy atak idzie z wielu adresów naraz. Limit po kluczu API albo koncie użytkownika jest dokładniejszy, o ile ruch jest zalogowany. W praktyce stosuje się kilka limitów jednocześnie — osobno na adres IP, na użytkownika i na konkretny endpoint, czyli pojedynczy adres usługi w API.

Jakie są algorytmy rate limitingu?

Sposób liczenia zapytań wpływa na trzy rzeczy: jak dokładny jest limit, jak bardzo toleruje chwilowe skoki ruchu (tzw. burst) i ile zużywa pamięci. Oto pięć najczęstszych podejść:

• Fixed window (stałe okno) — dzieli czas na równe odcinki (np. każda pełna minuta) i liczy zapytania w bieżącym odcinku. Prosty i oszczędny pamięciowo. Ma jednak słabość zwaną problemem granicy okna: wysyłając zapytania tuż przed końcem jednego okna i tuż po starcie następnego, klient może w krótkim czasie przepuścić podwójny limit.
• Sliding window log (przesuwne okno z logiem) — zapamiętuje dokładny czas każdego zapytania. Przy nowym zapytaniu usuwa te starsze niż długość okna i liczy resztę. Najdokładniejszy i najsprawiedliwszy, ale przy dużym ruchu zjada sporo pamięci.
• Sliding window counter (przesuwne okno licznikowe) — przybliża okno przesuwne. Bierze liczniki bieżącego i poprzedniego okna i waży je w zależności od tego, ile czasu już upłynęło. Dobry kompromis: prawie znosi problem granicy, a pamięci zużywa umiarkowanie.
• Token bucket (kubełek z żetonami) — kubełek napełnia się żetonami ze stałą szybkością, aż do pewnej pojemności. Każde zapytanie zużywa jeden żeton. Klient, który chwilę nie wysyłał zapytań, zbiera zapas żetonów i może potem nadrobić krótkim skokiem — przy zachowaniu średniego tempa. Częsty domyślny wybór dla publicznych API.
• Leaky bucket (cieknący kubełek) — zapytania trafiają do kolejki, która opróżnia się ze stałą szybkością. Gdy kolejka się przepełni, nadmiar jest odrzucany. Wymusza równe, wygładzone tempo bez miejsca na skoki — przydatny, gdy chcemy wyrównać ruch wychodzący.

Gdzie wdraża się rate limiting?

Ograniczanie tempa działa na wielu warstwach infrastruktury, często naraz:

• Brzeg sieci / CDN — zatrzymuje nadmiarowy lub złośliwy ruch jak najbliżej źródła, zanim dotrze do serwera docelowego.
• WAF (Web Application Firewall, czyli zapora aplikacji webowych) — łączy limity z regułami dla konkretnych ścieżek (np. ostre limity na /login i na wyszukiwarkę).
• API gateway (brama API) — egzekwuje zasady dla całego ruchu API, np. limity na klucz API, na plan abonamentu, na endpoint.
• Reverse proxy / load balancer — np. moduły rate limit w serwerach takich jak Nginx czy HAProxy.
• Warstwa aplikacji — najbardziej szczegółowa kontrola, oparta na logice biznesowej (np. limit kosztu zapytania, a nie tylko ich liczby).

W środowiskach rozproszonych liczniki muszą być wspólne dla wielu instancji (np. w bazie Redis). Pojawia się tu kompromis. Silna spójność daje dokładny limit, ale kosztem opóźnień. Spójność ostateczna jest szybsza, ale dopuszcza chwilowe przekroczenia.

Jak rate limiting chroni przed atakami?

Z perspektywy bezpieczeństwa rate limiting spowalnia i utrudnia atak, ale sam w sobie nie jest pełną ochroną:

• Brute force i credential stuffing — limit prób logowania na konto i na IP mocno spowalnia zgadywanie haseł oraz testowanie wykradzionych par login–hasło. Daje to zespołom czas na reakcję. (Brute force to zgadywanie hasła metodą prób i błędów; credential stuffing to masowe podstawianie danych wykradzionych z innych serwisów.)
• Ataki DDoS na warstwę aplikacji (L7) — odrzucanie żądań ponad próg ogranicza skutki zalewania kosztownych endpointów. Przy atakach wolumetrycznych, które po prostu zapychają łącze, potrzebne są dodatkowe mechanizmy na brzegu sieci.
• Scraping i nadużycia API — limity na klienta utrudniają masowe pobieranie danych i przeszukiwanie zasobów.
• Wyczerpanie zasobów — ograniczanie tempa, zwłaszcza oparte na koszcie żądania, chroni przed pojedynczymi klientami, którzy zjadają nieproporcjonalnie dużo procesora, pamięci czy łącza.

Dlaczego rate limiting jest ważny dla monitoringu i SOC?

Zdarzenia rate limitingu to cenna informacja dla zespołów bezpieczeństwa i monitoringu sieci (SOC to centrum operacji bezpieczeństwa, NDR to wykrywanie zagrożeń w ruchu sieciowym). Nagły wzrost odpowiedzi 429 z jednego klucza API albo z puli adresów to sygnał: ktoś próbuje nadużyć, klient jest źle skonfigurowany albo zaczyna się atak. Zestawienie liczby odrzuceń z konkretnymi endpointami (np. logowanie, reset hasła) pomaga odróżnić atak na konta od zwykłego skoku ruchu. Analiza wzorców żądań — jak często przychodzą, z jakich adresów IP i agentów, jak rozkładają się w ciągu doby — pozwala wykryć automatyzację i ruch botów, których samo blokowanie po progu może nie zauważyć.

Czym różni się rate limiting od throttlingu?

Pojęcia bywają mylone, ale różnią się reakcją na przekroczenie progu. Rate limiting egzekwuje twardy limit — żądania ponad próg są odrzucane (zwykle 429). Throttling jest łagodniejszy: przyjmuje żądania, ale zwalnia ich obsługę — opóźnia, kolejkuje albo obniża priorytet nadmiarowego ruchu, zamiast go odrzucać. W praktyce throttling bywa jedną z możliwych reakcji w ramach polityki rate limitingu, a wiele bram API stosuje oba podejścia razem.

Jak klient powinien reagować na 429?

Odpowiedź 429 Too Many Requests często zawiera nagłówek Retry-After, który mówi, ile klient ma odczekać przed kolejną próbą (w sekundach lub jako data). Wiele API dodaje też nagłówki informacyjne, np. X-RateLimit-Limit, X-RateLimit-Remaining i X-RateLimit-Reset. Dobrze napisany klient honoruje Retry-After i stosuje exponential backoff z jitterem — czyli wydłuża odstępy między próbami i dorzuca małą losową wartość, żeby ponowienia nie nadchodziły zsynchronizowanymi falami. Ignorowanie tych sygnałów tylko pogłębia przeciążenie.

Dowiedz się więcej

• Zaawansowane metody ochrony przed atakami DDoS w firmach — Rate limiting ogranicza tempo ruchu, co pomaga tłumić skutki ataków DDoS.
• Podatność IDOR – jak wykryć atak na aplikacje webowe przez analizę ruchu HTTP — Rate limiting utrudnia masowe próby odwołań do zasobów przy podatności IDOR.
• Błędy DNS i bezpieczeństwo DNS – DNSSEC, ochrona przed atakami DNS i DNS management errors — Rate limiting ogranicza nadmiar zapytań DNS i pomaga blokować nadużycia.
• API Security — Rate limiting jest podstawową kontrolą bezpieczeństwa API przed nadużyciami.