Rate limiting to mechanizm sterowania ruchem, który określa, ile żądań pochodzących od danego klienta system może obsłużyć w ustalonym czasie. Klientem może być:

 

• użytkownik,
• aplikacja,
• urządzenie,
• usługa korzystająca z API.

 

Limit dotyczy zwykle konkretnego zasobu, np. endpointu logowania albo operacji pobierania danych.

 

Mechanizm działa na poziomie infrastruktury lub aplikacji. Może stosować limit globalny, albo przypisywać żądania do określonego identyfikatora, a następnie porównywać ich liczbę z przyjętą regułą. Identyfikator może bazować na:

 

• adresie IP,
• kluczu API,
• koncie użytkownika,
• tokenie sesji,
• numerze urządzenia,
• zaufanym nagłówku HTTP,
• kombinacji kilku cech żądania.

 

Typowe reguły określają:

 

• zakres limitu – zasób lub operacja objęta kontrolą,
• próg – maksymalna liczba żądań,
• okno czasowe – okres, w którym system zlicza wywołania,
• reakcję – działanie wykonywane po przekroczeniu progu.

 

Po osiągnięciu limitu kolejne żądanie może zostać odrzucone lub opóźnione. Klient może wówczas otrzymać status HTTP 429 „Too Many Requests”.

   

Rate limiting ogranicza skuteczność ataków opartych na masowym wysyłaniu powtarzalnych żądań. Jest to coraz poważniejsze zagrożenie – w 2025 roku Cloudflare wykrył i zablokował 47,1 mln ataków DDoS, o 121% więcej niż rok wcześniej i 236% więcej niż w 2023 roku.

 

Rate limiting ogranicza skuteczność:

 

• DoS i DDoS – ograniczenie ruchu zmniejsza liczbę operacji obsługiwanych przez serwer i pomaga zachować dostępność aplikacji,
• brute force – limit prób logowania spowalnia zgadywanie danych uwierzytelniających,
• credential stuffing – kontrola częstotliwości żądań utrudnia masową weryfikację danych logowania,
• password spraying – limit przypisany do źródła ruchu lub grupy kont ogranicza tempo tej operacji,
• ataków słownikowych – ograniczenie liczby żądań wydłuża czas próby i ułatwia wykrycie nietypowej aktywności.

 

Efektywność tego mechanizmu zależy od prawidłowego przypisania limitu do identyfikatora.

   

Chcąc lepiej zrozumieć, co to jest rate limiting, warto przyjrzeć się jego algorytmom. Określają sposób zliczania żądań oraz moment egzekwowania limitu. Poszczególne metody różnią się dokładnością, zużyciem pamięci i możliwością obsługi krótkich skoków natężenia ruchu.

 

Fixed window

 

System zlicza żądania w okresach o ustalonej długości. Po zakończeniu okna licznik wraca do zera. Metoda jest prosta i wydajna. Może jednak dopuścić duży skok ruchu na granicy dwóch okresów.

 

Sliding window log

 

Mechanizm zapisuje czas każdego żądania. Przy nowym wywołaniu usuwa starsze wpisy i zlicza rekordy mieszczące się w aktualnym przedziale. Zapewnia wysoką precyzję kosztem większego zużycia pamięci.

 

Sliding window counter

 

Algorytm szacuje bieżący ruch na podstawie danych z dwóch sąsiednich okresów. Oferuje lepszą płynność niż stałe okno i wymaga mniej zasobów niż pełny rejestr.

 

Token bucket

 

Każde żądanie zużywa token, a pula uzupełnia się w stałym tempie. Zapas tokenów pozwala obsłużyć krótkotrwały wzrost ruchu przy zachowaniu średniego limitu.

 

Leaky bucket

 

Żądania są obsługiwane w równym tempie. Nadmiar wypełnia ustalony bufor, a po przekroczeniu jego pojemności kolejne wywołania zostają odrzucone.

   

Rate limiting warto stosować warstwowo, możliwie blisko miejsca, w którym ruch trafia do infrastruktury firmy. Wczesna kontrola ogranicza bowiem liczbę żądań przekazywanych do dalszych komponentów.

 

Rate limiting warto stosować:

 

• na brzegu sieci – reguły CDN lub WAF zatrzymują nadmiarowe żądania przed przekazaniem ich do serwera źródłowego,
• na reverse proxy i load balancerze – limiter kontroluje ruch kierowany do puli serwerów aplikacyjnych i może obejmować wybrane ścieżki,
• w API Gateway – mechanizm pozwala różnicować limity według trasy, metody, klienta, klucza API lub planu dostępu,
• przed usługą wewnętrzną – osobne limity zmniejszają ryzyko przeciążenia zależności między mikroserwisami i procesami zaplecza.

 

W raporcie Akamai Apps, APIs, and DDoS 2026 87% respondentów przyznało, że ich organizacja doświadczyła w 2025 roku przynajmniej jednego incydentu bezpieczeństwa związanego z API. Jedną z dobrych praktyk w ochronie interfejsów przed przeciążeniem i atakami automatycznymi jest precyzyjne zarządzanie limitami żądań (rate limiting). Warto dbać o ich dynamiczną adaptację w czasie – inne parametry przepustowości sprawdzą się w standardowym ruchu, a inne w okresach planowanych szczytów sprzedażowych, takich jak np. Black Friday.

   

Rate limiting stanowi jedną z warstw kontroli aktywności sieciowej. Można uzupełnić ją usługami Netii, które filtrują ruch, chronią aplikacje i wspierają reakcję na incydenty:

 

• Netia DDoS Protection – zapewnia całodobowy monitoring i przekierowuje podejrzane pakiety do platformy o wydajności 200 Gb/s, która odfiltrowuje szkodliwy ruch. Dzięki redundantnym rozwiązaniom dostępność usługi wynosi ponad 99,99%.
• Netia Managed WAF – analizuje żądania kierowane do aplikacji webowych i blokuje ruch uznany za szkodliwy lub sztuczny. Usługa chroni także przed atakami z listy OWASP Top 10 oraz ruchem botnetów. Może obejmować ochroną ruch aplikacyjny do 100 Mbit/s.
• Security Operations Center – monitoruje zdarzenia bezpieczeństwa w modelu 24/7/365. SOC Netii wykorzystuje dwa systemy SIEM i platformę SOAR, która automatyzuje analizę i obsługę incydentów.

 

Takie połączenie zwiększa odporność infrastruktury na przeciążenia i ataki aplikacyjne.