Rate limiting određuje koliko saobraćaja jedan klijent, API ključ ili tenant smije poslati prije nego aplikacija počne odbijati višak. Bez te kontrole skripta, procurjeli ključ ili bučna integracija mogu isprazniti bazu, podići račun za hosting i zaključati prave kupce na prijavi ili checkoutu.
Sadržaj
CodeWiz te kontrole postavlja na javne API-je, SaaS proizvode, online prodavnice i web stranice koje već imaju stvaran saobraćaj. Limite stavljamo na edge, u API gateway i u samu aplikaciju, vežemo ih za pravi identitet i dodajemo odgovore, metrike i alarme tako da 429 bude svjesna odluka. Ova stranica je o tom poslu isporuke. Algoritmi su u našem vodiču za API rate limiting, a Express middleware u članku o rate limitingu u Node.js-u i Expressu.
Namijenjena je timovima kojima se prijava, pretraga, checkout ili javni API stružu, pune tuđim lozinkama ili rastu brže nego što jedan zajednički brojač može izdržati. Limiti koji žive u memoriji procesa i nestanu pri svakom deployu već rade protiv vas.
Kod teme throttling alati otvorenog koda su prvi izbor kada odgovaraju poslu.
Throttling zahtjeva: rate limiting po endpointu
Throttling zahtjeva ograničava koliko često pozivalac smije pogoditi jednu radnju. Provjera lozinke, pretraga proizvoda i webhook ne dijele isti budžet. Limit postavljamo po ruti, biramo kome brojač pripada i definišemo šta je “previše” za tu radnju.
Šta ograničavamo i po kom ključu
- Prijava, OTP i reset lozinke idu tijesno po nalogu i po IP adresi, jer su te rute uobičajena meta credential stuffinga i zatrpavanja inboxa.
- Pretraga, filteri i izvozi idu po korisniku ili API ključu, jer svaki poziv može biti skup i kada je pozivalac legitiman.
- Checkout i pokušaji plaćanja ostaju široki za pravog kupca, a strogi za ponovljene greške, tako da ponovni pokušaj kartice ne liči na napad niti napad na kupca.
- Javni i partnerski API-ji idu po ključu, uz poseban plafon za saobraćaj bez autentifikacije.
- Webhookovi koje primate od payment provajdera i kurira stoje na listi dozvoljenih i prolaze provjeru, umjesto da padnu u isti koš sa anonimnim browserima.
Iza Cloudflarea adresa socketa je proxy, pa limit po IP adresi ili blokira sve ili ne blokira nikoga. Dokumentovani header sa IP adresom klijenta vjerujemo samo od proxyja kojima sami upravljamo, nikad od headera koji pozivalac može sam postaviti.
Mali primjer na edgeu
Na Nginxu ruta za prijavu može odbiti nalet prije nego što PHP ili Node.js uopšte krene. Ovo je skica, ne gotova politika:
limit_req_zone $binary_remote_addr zone=login:10m rate=5r/m;
limit_req_status 429;
server {
location /login {
limit_req zone=login burst=10 nodelay;
proxy_pass http://app;
}
}Nginx modul limit_req dovoljan je za jedan server. Čim ima više instanci, brojač se seli u Redis ili na edge, inače svaki proces primjenjuje drugi broj. Biblioteke se razlikuju po frameworku; te detalje držimo u Express članku da ova stranica ostane na usluzi.
DDoS zaštita prije nego saobraćaj stigne do origina
DDoS zaštita i throttling po ruti rješavaju srodne probleme na različitim slojevima. Volumetrijski nalet puni cijev. Aplikacijski nalet šalje jeftine HTTP zahtjeve koji su pojedinačno ispravni, a zajedno razorni: pretraga, prijava, dodavanje u korpu, stranice bez keša. Limit unutar aplikacije nikad ne vidi prvu vrstu, a mrežni filter često ignoriše drugu.
Cloudflare stoji ispred origina i upija volumetrijski saobraćaj. Pravila za ograničenje zahtjeva, WAF pravila i bot score zaustavljaju ponavljajuću zloupotrebu prije nego potroši PHP workere, Node.js procese ili konekcije prema bazi. Širi setup pokriva naš vodič za Cloudflare konfiguraciju. Podešavamo Cloudflareova pravila za limit zahtjeva po IP adresi, putanji, metodi i headeru.
Šta ide na edge, a šta ne
- Blokirajte ili izazovite očigledne nalete, poznate loše user agente i putanje koje ne smiju biti javne.
- Keširajte anonimne odgovore da skok istog URL-a nikad ne stigne do origina. Keširana stranica je jeftinija od odbijene.
- Limite svjesne naloga, kvote paketa i odluku “ovaj API ključ je potrošio budžet” držite u aplikaciji, tamo gdje identitet stvarno postoji.
- Izazov poput Turnstilea koristite na registraciji i resetu lozinke kada su problem botovi, a preskočite ga na rutama gdje pravi API klijent ne može ga riješiti.
Postavljamo oba sloja, pa testom opterećenja provjeravamo da origin ostane na nogama dok edge drži nalet i da se uredno povuče kada poplava ipak prođe.
Upravljanje saobraćajem i pravila fer upotrebe
Upravljanje saobraćajem je poslovna odluka sakrivena u tehničkoj. Besplatni paket, klijent koji plaća i interni posao ne smiju dijeliti jedan koš. Fer upotreba sprečava da jedan tenant izgladnjuje ostale i daje vam način da prodate veće limite bez prepisivanja API-ja.
| Pozivalac | Uobičajeni ključ | Trajni budžet | Nalet | Kada je budžet potrošen |
|---|---|---|---|---|
| Anonimni posjetilac | IP klijenta i putanja | Nizak | Mali | 429 ili keširan javni odgovor |
| Prijavljen kupac | Id korisnika | Udoban za čovjeka | Kratak skok dozvoljen | 429 sa Retry-After, sučelje kaže koliko se čeka |
| API ključ, besplatni paket | Id ključa | Dnevna kvota plus limit po minutu | Ograničen | 429 i header potrošnje koji klijent može pročitati |
| API ključ, plaćeni paket | Id ključa i paket | Ugovorena kvota | Viši | 429, pa alarm vašem timu ako se ponavlja |
| Interni worker | Identitet servisa | Poseban bazen | Usklađen sa veličinom batcha | Pritisak na red, nikad greška prema kupcu |
Politiku dokumentujemo uz API: koje su rute mjerene, koji se headeri vraćaju (Retry-After u najmanju ruku) i koji status znači “usporite”, a koji “zabranjeno”. Klijent koji na svaki 429 odmah pokuša ponovo pogoršava incident. To je rupa opisana u OWASP napomeni o neograničenoj potrošnji resursa.
Sigurnosne mjere izgrađene oko rate limitinga
Sam brojač ne čini endpoint sigurnim. Zatvara rupu tamo gdje autentifikacija, validacija i keš nisu dovoljni: pozivalac smije pokušati, ali ne zauvijek. Budžet spajamo sa kontrolama koje mu daju smisao.
- Autentifikacija i dalje odlučuje o pristupu. Limit na otvorenoj admin ruti nije autorizacija.
- Greške su strože od uspjeha. Deset pogrešnih lozinki je napad; deset pregleda stranice je korisnik. Jedan zajednički brojač ili kažnjava kupce ili pušta stuffing da traje.
- Skup posao dobija svoju kvotu. PDF-ovi, transformacije slika, AI pozivi i pretraga bez indeksa mogu koštati koliko i hiljadu jeftinih zahtjeva.
- Odgovori ne otkrivaju naloge. “Korisnik nije pronađen” i “pogrešna lozinka” ostaju istog oblika, a reset lozinke je ograničen po adresi da ne može mapirati tabelu korisnika niti poplaviti inbox.
- Webhookovi se provjere, pa izuzmu. Potpisani callbackovi payment i kurirskih provajdera ne smiju pasti na anonimnom IP pravilu kada provajder ponovi pokušaj.
- Zaključavanja ističu. Kratka odgoda sigurnija je od trajnog lokota koji napadač može okrenuti na tuđem nalogu.
Gdje limiti žive: edge, gateway, aplikacija i podaci
Edge pravila su brza i slijepa za vašu tabelu korisnika. Brojači u aplikaciji znaju tenanta i paket. Koristimo najjeftiniji sloj koji i dalje zna dovoljno, a bazu tretiramo kao sigurnosnu mrežu, ne kao politiku.
| Sloj | Zna o | Dobar je u | Slab je u | Koristimo ga za |
|---|---|---|---|---|
| CDN / WAF (Cloudflare) | IP, putanja, headeri, bot score | Naleti, anonimna zloupotreba, jeftina odbijanja | Paketi po korisniku i stanje naloga | Prva linija ispred svakog javnog origina |
| API gateway ili reverse proxy | Ruta, API ključ, klijentski certifikat | Partnerski API-ji, zajednička politika preko servisa | Duboka poslovna pravila | Javni i partnerski API-ji sa više backendova |
| Aplikacija + Redis | Korisnik, tenant, paket, uspjeh ili greška | Fer upotreba, prijava, kvote koje moraju pratiti naplatu | Zaustavljanje naleta koji je već u procesu | Sve što zavisi od toga ko zove |
| Baza i limiti poola | Konekcije i cijena upita | Posljednja zaštita skladišta podataka | Jasan odgovor klijentu | Sigurnosna mreža, ne primarna politika |
Limit koji stoji u jednom Node.js ili PHP procesu drugi je limit na svakom serveru i resetuje se kad god se proces ponovo pokrene. Redis, sa kratkim TTL-om i atomskim uvećanjem, daje svakoj instanci isti odgovor. Ako edge već provodi pravilo, ne prepisujemo ga u aplikaciju.
Izbor prozora, naleta i kvota
Fiksni prozor, klizni prozor i token bucket ne slažu se na granici prozora i na kratkim naletima. Nemarno pravilo “100 u minuti” može propustiti 200 u dvije sekunde ili odbiti običan ponovni pokušaj checkouta. Algoritam biramo po ruti. Kompromisi i primjeri koda su u vodiču iz uvoda. Sami brojevi dolaze iz dokaza:
- Logovi i metrike najprometnijeg sata: p95 i najgori legitimni nalet, ne prosjek.
- Poseban, stroži broj za neuspjele autentifikacije.
- Dozvola naleta da stranica koja ispali nekoliko poziva odjednom i dalje učita.
- Dnevna ili mjesečna kvota samo tamo gdje je komercijalni paket traži; ispod nje i dalje stoji limit po sekundi.
- Prolaz na stagingu sa skriptom koja se ponaša pristojno i skriptom koja ne, da vidimo i 429 i putanju kupca koja nije dirnuta.
Brojevi žive u konfiguraciji, ne kao magične vrijednosti u kontrolerima, i svako odbijanje bilježi koje je pravilo puklo. Doterivanje poslije puštanja je očekivano; doterivanje bez tog loga je nagađanje.
Kvote za multi-tenant proizvode i javne API-je
Kad pristup prodajete, kvota postaje dio ponude. Besplatni, timski i enterprise paketi trebaju različite budžete, a jedan zajednički ključ za cijelu firmu nije isti problem kao ključ po integraciji. Ključ, tenanta i paket modelujemo odvojeno, tako da nadogradnja mijenja kvotu, a ne deploy.
- Ključevi se rotiraju i povlače bez gašenja tenanta.
- Headeri u odgovoru pokazuju preostali budžet, pa partner može usporiti prije tvrdog zaustavljanja.
- Batch poslovi i odlazni webhookovi troše poseban budžet, tako da noćna sinhronizacija ne pojede interaktivnu kvotu.
- Ponovni pokušaji ostaju sigurni. Drugi pokušaj poslije 429 ne smije napraviti drugu narudžbu niti drugu naplatu, što znači da idempotency ključevi stoje u istom dizajnu kao kvota.
Uobičajene greške throttlinga koje ispravljamo
Većina postavki koje nas zovu da popravimo dodana je u žurbi poslije incidenta. Ponavljaju se iste rupe:
- Jedan globalni limit za cijeli sajt, pa scraper na pretrazi blokira i checkout.
- Pravila samo po IP adresi iza proxyja, koja ili guše proxy ili vjeruju headeru koji se može falsifikovati.
- Brojači u memoriji na deployu sa više instanci, pa je stvarni limit “limit puta broj servera”.
- 429 bez
Retry-After, što uči klijente i botove da odmah pokušaju ponovo. - Nema dashboarda. Saznate da su pravi korisnici blokirani tek kad pišu podršci.
- Webhookovi plaćanja i dostave upali u anonimno pravilo i tiho odbačeni.
- Trajna zaključavanja koja napadač može okrenuti na nalogu žrtve.
Od čega zavisi cijena
Procjenu dajemo nakon kratkog pregleda ruta, saobraćaja i mjesta gdje zloupotreba ili usporenje stvarno jesu. Posao raste sa nekoliko konkretnih faktora:
- Koliko ruta treba vlastitu politiku, posebno prijava, pretraga, checkout i javni API-ji.
- Da li je limit jedno Nginx ili Cloudflare pravilo, ili Redis kvota vezana za pakete naplate.
- Koliko instanci aplikacije i okruženja mora dijeliti iste brojače.
- Da li klijentima trebaju dokumentovani headeri, oblik greške i period prelaska za postojeće ključeve.
- Test opterećenja i dashboardi, koje računamo kao dio posla, a ne kao dodatak.
Jedna osjetljiva ruta na postojećem Cloudflare i Redis stacku mali je posao. Javni API sa nekoliko paketa i periodom prelaska za sadašnje klijente veći je. Kažemo koji je koji prije nego što gradimo.
Kako radimo
- Upoznavanje: popisujemo skupe, osjetljive ili već zloupotrebljene rute i čitamo logove, CDN pravila i način na koji se klijenti identifikuju.
- Plan: biramo sloj, ključ, prozor i odgovor i dogovaramo šta se nikad ne ograničava, poput health checkova i potpisanih webhookova.
- Izrada: dodajemo edge pravila, dijeljene brojače i provjere u aplikaciji i vraćamo dosljedan 429 sa
Retry-After. - Test: pristojan klijent i zlonamjeran klijent idu na staging, na više od jedne instance, dok stvarni tokovi korisnika i dalje prolaze.
- Puštanje: krećemo u report-only režimu ili sa širokim plafonima, pa stežemo kad grafovi odgovaraju onome što smo očekivali.
- Podrška: dashboardi, alarm na neuobičajenu stopu 429 odgovora i bilješka kako promijeniti limit bez lova kroz kod.
Zašto CodeWiz
- Aplikacija i infrastruktura zajedno: gradimo Laravel, Node.js, WordPress i API kod, pa limit stoji tamo gdje je zahtjev stvarno skup.
- Open-source na prvom mjestu: Nginx, Redis i vaš postojeći framework nose politiku, uz Cloudflare tamo gdje je edge pravo mjesto. Niste vezani za licencu uskog gatewaya.
- Prilagođeno ruti: prijava, checkout, pretraga i partnerski API-ji dobijaju različite budžete. Jedan globalni broj je obrazac koji obično uklanjamo.
- Poštene cijene: vrhunski razvoj bez vrhunskih cijena, iz Banje Luke, na daljinu sa klijentima lokalno i u inostranstvu.
- Sigurnost i performanse zajedno: throttling, keširanje, Cloudflare i hardening ostaju u jednom briefu. Više o studiju je na stranici o CodeWizu.
Često postavljana pitanja
Koliko košta throttling projekat?
Nekoliko ruta na stacku koji već ima Cloudflare ili Redis kratak je angažman. Multi-tenant API sa paketima, headerima potrošnje i bilješkama za partnere traje duže, jer je politika dio proizvoda. Ponudu dajemo nakon pregleda ruta i saobraćaja.
Koliko traje tipična implementacija?
Prijava i nekoliko skupih ruta često su zaštićene u roku od nekoliko dana, uključujući test na stagingu. Dokumentovana kvota na postojećem javnom API-ju traje duže, uglavnom da sadašnji klijenti stignu da se prilagode novim headerima i statusnim kodovima.
Hoće li pravi kupci biti blokirani?
Samo ako plafon stoji ispod normalne sesije. Limite dimenzionišemo prema vašem najprometnijem satu, ostavljamo kratak nalet za stranice koje ispale nekoliko zahtjeva i pratimo stopu 429 odgovora nakon puštanja, tako da osoba na checkoutu nije ona koja čeka.
Da li je Cloudflare dovoljan sam po sebi?
Pravo je mjesto da se zaustave anonimni naleti i izazovu botovi. Ne zna da je API ključ na besplatnom paketu, niti da je lozinka pet puta bila pogrešna. Ta pravila žive u aplikaciji. Većina postavki koje isporučujemo koristi oba sloja.
Možete li dodati limite na postojeću Laravel, WordPress ili Node.js aplikaciju?
Da. Obično ostavljamo aplikaciju na mjestu i dodajemo edge pravila plus dijeljeni brojač oko ruta kojima trebaju. Pristup Express middlewareu je članak iz uvoda. WordPress i Laravel dobijaju istu politiku alatima koje ti stackovi već koriste.
Treba vam throttling koji odgovara proizvodu?
Recite nam koje su rute spore, skupe ili već zloupotrebljene, pa ćemo predložiti throttling koji ih štiti a ne smeta pravim korisnicima. Kontaktirajte nas da prođemo saobraćaj, ili pogledajte cijelu ponudu naših usluga rate limitinga i throttlinga.