Rate Limiting (Ograniczanie częstotliwości zapytań i ochrona API)

1. Przegląd koncepcji i problem systemowy

Bez niezawodnego mechanizmu ograniczania częstotliwości zapytań (rate limiting) każdy publicznie dostępny serwis webowy lub endpoint API narażony jest na stałe ryzyko awarii technicznej lub finansowej:

• Wyczerpanie budżetu AI (AI Billing Drain): Atakujący lub zapętlony skrypt może wysłać 100 000 żądań do Twojego routingu generującego kod lub obrazy w ciągu zaledwie 5 minut, generując rachunek rzędu $5,000 od OpenAI lub Anthropic.
• Brute-force i Credential Stuffing: Zautomatyzowane botnety próbują milionów kombinacji haseł na formularzu logowania /api/auth/login, przeciążając bazę danych kosztownymi operacjami hashowania bcrypt/Argon2.
• Kaskadowa awaria bazy danych (Denial of Service): Masowe, równoległe wywołania niekaszowanych endpointów wyszukiwania wyczerpują pulę połączeń PostgreSQL, paraliżując działanie całej aplikacji.

Rate Limiting to fundamentalna tarcza bezpieczeństwa systemowego. Mierzy on intensywność ruchu na podstawie identyfikatora (adres IP, ID sesji, klucz API) i odcina nadmiarowy ruch na wczesnym etapie potoku przetwarzania, zapewniając przewidywalność obciążenia oraz ciągłość obsługi legalnych użytkowników.

2. Taksonomia architektoniczna i model mentalny

Wybór architektoniczny algorytmów i poziomów implementacji ograniczania ruchu:

┌─────────────────────────────────────────────────────────────┐
│                 TAKSONOMIA ALGORYTMÓW LIMITOWANIA RUCHU     │
├─────────────────────────────────────────────────────────────┤
│ 1. Fixed Window: Prosty licznik resetowany co minutę        │
│    (Podatny na skoki ruchu o 2x na granicy interwału)       │
├─────────────────────────────────────────────────────────────┤
│ 2. Sliding Window Counter: Hybrydowe okno przesuwne         │
│    Weight = Prev_Count * (1 - Elapsed_Ratio) + Curr_Count   │
│    (Idealny kompromis: dokładność + minimalne zużycie RAM)  │
├─────────────────────────────────────────────────────────────┤
│ 3. Token Bucket: Uzupełnianie tokenami ze stałą prędkością  │
│    (Pozwala na uzasadnione skoki ruchu do pojemności wiadra)│
├─────────────────────────────────────────────────────────────┤
│ 4. Leaky Bucket: Stała prędkość „przeciekania” kolejki      │
│    (Optymalne dla wygładzania zapytań wychodzących do API)  │
└─────────────────────────────────────────────────────────────┘

1. Hybrydowe przesuwanie okno (Sliding Window Counter):
   • Przechowuje liczniki dla bieżącego i poprzedniego interwału czasowego. Przy każdym żądaniu oblicza ważoną sumę na podstawie tego, jaki procent czasu upłynął w bieżącym oknie. Eliminuje anomalie na styku minut.
2. Hierarchia identyfikatorów klienta (Subject Identification):
   • Poziom publiczny: Adres IP (dla anonimowych żądań i ochrony przed DDoS).
   • Poziom uwierzytelniony: User_ID lub Organization_ID (ignoruje wspólne korporacyjne sieci NAT/VPN).
   • Poziom tokenowy: Granularne limity kwotowe w zależności od typu wykupionego planu (Free, Pro, Enterprise).
3. Rozproszony backend przechowywania stanu (Redis Cluster / Upstash):
   • Centralizowany magazyn pamięci szybkiej (In-Memory), który synchronizuje liczniki między dziesiątkami instancji backendu w mikrosekundach.

3. Potok techniczny i mechanika wewnętrzna

Cykl życia walidacji żądania przez Redis z użyciem atomowego skryptu Lua:

1. Ekstrakcja identyfikatora i ścieżki: Middleware przechwytuje przychodzące żądanie. Tworzony jest złożony klucz: rate:auth:${req.ip} dla formularza logowania lub rate:llm:${user.id} dla routingu AI.
2. Atomowe wykonanie skryptu Lua w Redis: Aby uniknąć warunków wyścigu (Race Condition) między równoległymi żądaniami, cała logika jest pakowana w jeden skrypt Lua:
   • Odczytywany jest bieżący timestamp.
   • Usuwane są wpisy starsze niż rozmiar przesuwającego się okna (60 sekund).
   • Obliczana jest liczba aktywnych tokenów.
3. Podejmowanie decyzji:
   • Jeśli limit nie został przekroczony: Licznik jest zwiększany o 1 (lub o koszt żądania w tokenach), ustawiany jest TTL klucza, a żądanie jest przekazywane dalej do kontrolera.
   • Jeśli limit został przekroczony: Generowana jest odpowiedź odmowna.
4. Tworzenie standardowych nagłówków HTTP: Serwer zwraca klientowi metadane:

   HTTP/1.1 429 Too Many Requests
   Content-Type: application/json
   Retry-After: 24
   X-RateLimit-Limit: 10
   X-RateLimit-Remaining: 0
   X-RateLimit-Reset: 1718293840
   

5. Telemetria i alerting: Wydarzenie przekroczenia limitu jest rejestrowane w systemie monitoringu; w przypadku anomalouskiego wzrostu ruchu z jednej podsieci uruchamiana jest reguła blokowania w firewallu.

4. Praktyczne scenariusze inżynieryjne w środowisku produkcyjnym

01. Ochrona drogich routingów generatywnych AI (Token-Aware Limiting)

Routing generowania kodu pobiera opłaty proporcjonalnie do złożoności żądania:

• Zamiast prostego liczenia żądań, limiter rate-limitingowy pobiera z wirtualnego salda użytkownika dokładną liczbę wygenerowanych tokenów.
• Użytkownicy darmowego planu mają limit 50 000 tokenów dziennie. Po wyczerpaniu limitu API blokuje generowanie do początku kolejnej doby.

02. Ochrona formularza uwierzytelniania przed brute-force (Credential Defense)

Endpoint /api/auth/sign-in:

• Zezwala na maksymalnie 5 nieudanych prób wprowadzenia hasła w ciągu 15 minut dla jednej kombinacji IP + Email.
• Przy 6. próbie system wymaga przejścia CAPTCHA lub wysyła link do resetowania hasła na e-mail, całkowicie niwelując próby ataku słownikowego.

03. Wygładzanie ruchu wychodzącego do zewnętrznych bramek płatniczych

Integracja ze Stripe, gdzie obowiązuje limit 100 żądań na sekundę:

• Wewnętrzny mikroserwis wykorzystuje kolejkę z algorytmem Leaky Bucket.
• Nawet jeśli wewnętrzni agenci firmy jednocześnie tworzą 500 płatności podczas Black Friday, kolejka wysyła żądania ściśle równomiernym strumieniem (80 req/s), eliminując ryzyko zablokowania konta Stripe.

5. Pułapki, typowe błędy i bezpieczeństwo

• Blokowanie całych biur przez naiwny Rate Limiting po IP: Jeśli zastosujesz surowy limit wyłącznie po adresie IP dla zalogowanych użytkowników, jeden aktywny pracownik biurowca zablokuje pracę wszystkich swoich kolegów, którzy korzystają z internetu przez wspólny adres NAT firmy. Po zalogowaniu zawsze stosuj limity po user_id.
• Warunki wyścigu (Race Condition) przy używaniu rozdzielonych operacji GET i INCR: Jeśli sprawdzasz limit komendą GET, a następnie zwiększasz go przez INCR, atakujący może wysłać 100 jednoczesnych asynchronicznych żądań, które wszystkie przejdą walidację przed aktualizacją licznika. Używaj skryptów atomowych.
• Przepełnienie pamięci Redis przy przechowywaniu znaczników czasu: Używanie nieposortowanych list do przechowywania znaczników czasu każdego żądania bez ustawienia sztywnego TTL szybko zapełnia gigabajty pamięci RAM podczas masowego ataku.
• Ignorowanie nagłówków proxy (X-Forwarded-For Spoofing): Jeśli Twój serwer stoi za Cloudflare lub Nginx i czytasz IP bezpośrednio z gniazda, otrzymasz lokalny adres proxy. Z drugiej strony, ślepe zaufanie niesprawdzonemu nagłówkowi X-Forwarded-For pozwala atakującemu sfałszować dowolny adres IP.