Dasturlash kitobi/14-QISM — Xavfsizlik44 daqiqa

14.8-bob: Rate limiting va DoS himoyasi

14-QISM — Web Xavfsizligi · 8-mavzu

1. Kirish va motivatsiya

Hozirgacha biz ma'lum bitta so'rov orqali bo'ladigan hujumlarni ko'rdik (XSS, injection, CSRF). Endi ko'plik orqali bo'ladigan hujumlarni ko'ramiz: bir foydalanuvchi (yoki bot) juda ko'p so'rov yuborib zarar yetkazadi. Rate limiting (so'rovni cheklash) — bir manbadan (IP, foydalanuvchi, API kalit) ma'lum vaqtda qancha so'rov qabul qilishni cheklash. Bu uch muammoni hal qiladi: brute force (parolni minglab marta sinash — 14.5), API suiiste'mol (resurslarni ortiqcha ishlatish, ma'lumot skanerlash), va DoS (Denial of Service — serverni so'rov bilan to'ldirib ishdan chiqarish — 14.1: CIA — Availability).

Rate limiting ko'pincha e'tibordan chetda qoladi (dasturchi "kim shuncha so'rov yuboradi?" deb o'ylaydi), lekin u juda muhim: rate limit'siz login — brute force'ga ochiq (zaif parol buziladi); rate limit'siz API — bot ma'lumotni skanerlaydi yoki resurslarni tugatadi (qimmat — bulut hisobi, OpenAI tokenlar); rate limit'siz forma — spam. Va DoS/DDoS — serverni ataylab to'ldirib (millionlab so'rov), haqiqiy foydalanuvchilar kira olmay qoladi (xizmat to'xtaydi — biznes zarari). Bu bob so'rov hajmini boshqarishni (algoritmlar, sozlash, DoS himoyasi) ko'rsatadi.

Bu bob: rate limiting nima va nega, algoritmlar (fixed window, sliding window, token bucket, leaky bucket), rate limit darajalari (IP, foydalanuvchi, endpoint, global), amaliy sozlash (Express, Next.js, Redis, Upstash), DoS/DDoS (turlari, himoya — CDN, WAF), va boshqa abuse himoyasi (CAPTCHA, javob normallashtirish) — barchasi to'liq ochib beriladi.

O'xshatish: Rate limiting — bu klubdagi navbatchi (bouncer) va kvota. Bouncer har odamga "soatda 5 marta kirib-chiqishingiz mumkin" deydi (rate limit). Agar kimdir tinmay kirib-chiqaversa (brute force — parol sinash, yoki spam) — bouncer uni to'xtatadi ("juda ko'p, kuting"). Bu ham haqiqiy mehmonlarni (server resurslari) himoyalaydi (bir kishi eshikni band qilmasin), ham yomon niyatli odamni to'sadi. DoS — bu yuzlab odam ataylab eshikka tiqilib, haqiqiy mehmonlar kira olmasligi (xizmat to'xtaydi); DDoS — bu minglab joydan (turli IP — botnet) bir vaqtda tiqilish. Himoya — kuchli bouncer (rate limit) + tashqi qo'riqchi (CDN/WAF — eshikka yetishdan oldin filtrlash). Rate limit — adolat (har kimga kvota) va himoya (suiiste'mol/hujumni to'sish).

Nega muhim?

Brute force — rate limit'siz login = zaif parol vaqt masalasi 14.5-bob.
API suiiste'mol — bot resurslarni (qimmat — bulut, AI tokenlar) tugatadi, ma'lumot skanerlaydi.
DoS/DDoS — serverni to'ldirib ishdan chiqarish (xizmat to'xtaydi — biznes zarari).
Adolat — bir foydalanuvchi resurslarni band qilmasin (boshqalarga ham yetsin).

2. Nazariya — chuqur tushuntirish

2.1. Rate limiting nima va nega

text

  RATE LIMITING — bir manbadan ma'lum vaqtda so'rovni CHEKLASH:

  MISOL: "bir IP — daqiqada 100 so'rov" (101-so'rov  429 rad)

  NIMANI HAL QILADI:
  1. BRUTE FORCE — parol/token sinash cheklanadi 14.5-bob
  2. API SUIISTE'MOL — bot ma'lumot skanerlash/resurs tugatish (qimmat)
  3. DoS — serverni so'rov bilan to'ldirish (xizmat to'xtaydi)
  4. SPAM — forma/izoh spam
  5. ADOLAT — bir foydalanuvchi resurslarni band qilmasin

  429 TOO MANY REQUESTS (rate limit javobi):
   status 429 + Retry-After header (qachon qayta urinish)
  HTTP/1.1 429 Too Many Requests
  Retry-After: 60

   Rate limiting — bir manbadan vaqtda so'rov cheklash (brute force/DoS/abuse/adolat)
   Limit oshsa — 429 (Too Many Requests) + Retry-After (qachon qayta)

Rate limiting nima va nega — so'rov hajmini cheklash. Rate limiting — bir manbadan (IP, foydalanuvchi, API kalit) ma'lum vaqtda qabul qilinadigan so'rovlarni cheklash (masalan "bir IP — daqiqada 100 so'rov" — 101-so'rov rad). Nimani hal qiladi: (1) brute force — parol/token sinash cheklanadi (14.5 — login'da rate limit — zaif parolni ham himoyalaydi); (2) API suiiste'mol — bot ma'lumot skanerlash (barcha mahsulot/foydalanuvchini yuklab olish) yoki resurs tugatish (qimmat — har so'rov bulut/AI token sarflaydi — rate limit'siz bot minglab so'rov katta hisob); (3) DoS — serverni so'rov bilan to'ldirish (xizmat to'xtaydi — 2.5); (4) spam — forma/izoh spam (bot minglab izoh); (5) adolat — bir foydalanuvchi resurslarni band qilmasin (boshqalarga ham yetsin). 429 Too Many Requests (rate limit javobi): limit oshsa, server 429 status + Retry-After header (qachon qayta urinish — Retry-After: 60 — 60 soniyadan keyin) qaytaradi (mijoz to'g'ri ishlov beradi — kutadi). Ikki nuqta: (1) rate limiting — bir manbadan vaqtda so'rov cheklash (brute force, DoS, API abuse, spam, adolat — bir vosita, ko'p muammo); (2) limit oshsa — 429 (Too Many Requests) + Retry-After (REST semantika — mijoz qachon qayta urinishni biladi). Rate limiting — ilovaning so'rov hajmidan himoyasi (bir so'rov hujumlari — XSS/injection — kod himoyasi; ko'p so'rov hujumlari — rate limit). Har muhim endpoint (login, API, forma) rate limit bilan bo'lishi kerak (suiiste'mol va hujumni to'sadi).

2.2. Rate limiting algoritmlari

text

  RATE LIMITING ALGORITMLARI (qanday hisoblash):

  1. FIXED WINDOW (sobit oyna — oddiy):
   har daqiqa (00:00-00:59) — 100 so'rov; keyin reset
   chegara muammosi: 00:59'da 100 + 01:00'da 100 = 1 soniyada 200

  2. SLIDING WINDOW (suriluvchi oyna — aniqroq):
   oxirgi 60 soniya (har payt) — 100 so'rov
   chegara muammosi yo'q (silliq)

  3. TOKEN BUCKET (token chelagi — moslashuvchan):
   chelakda tokenlar (har so'rov 1 token); token davriy to'ldiriladi
   burst (qisqa portlash) OK, lekin o'rtacha cheklangan

  4. LEAKY BUCKET (oqib turadigan chelak):
   so'rovlar navbatda, sobit tezlikda "oqadi" (qayta ishlanadi)
   tekis tezlik (burst silliqlanadi)

  ┌────────────────────────────────────────────────────────────┐
  │ Fixed (oddiy, chegara muammosi) | Sliding (aniq, silliq)    │
  │ Token bucket (burst OK) | Leaky bucket (tekis tezlik)       │
  └────────────────────────────────────────────────────────────┘

   Algoritmlar: fixed window (oddiy), sliding window (aniq), token bucket (burst)
   Ko'p kutubxona sliding window yoki token bucket (aniqroq — fixed chegara muammosi)

Rate limiting algoritmlari — so'rovlarni qanday hisoblash. To'rt asosiy algoritm: (1) fixed window (sobit oyna — eng oddiy): har sobit vaqt oynasida (masalan har daqiqa — 00:00-00:59) N so'rov, keyin reset (00:00'da qayta 0'dan); kamchilik — chegara muammosi: foydalanuvchi 00:59'da 100 so'rov + 01:00'da 100 so'rov yuborsa — 1 soniya ichida 200 so'rov (oyna chegarasida ikki baravar — limit buziladi); (2) sliding window (suriluvchi oyna — aniqroq): "oxirgi 60 soniya" (har payt — doimo orqaga 60 soniya) N so'rov; chegara muammosi yo'q (silliq — har vaqt oynasi suriladi); (3) token bucket (token chelagi — moslashuvchan): chelakda tokenlar bor (har so'rov 1 token sarflaydi), tokenlar davriy to'ldiriladi (masalan soniyada 2 ta) — chelak bo'sh bo'lsa rad; afzallik — burst (qisqa portlash — masalan birdan 10 so'rov) OK (chelakda token bo'lsa), lekin o'rtacha tezlik cheklangan; (4) leaky bucket (oqib turadigan chelak): so'rovlar navbatda (chelakda), sobit tezlikda "oqadi" (qayta ishlanadi) — burst silliqlanadi (tekis tezlik). Ikki nuqta: (1) algoritmlar — fixed window (oddiy, lekin chegara muammosi), sliding window (aniq, silliq), token bucket (burst OK — moslashuvchan), leaky bucket (tekis tezlik); (2) ko'p kutubxona sliding window yoki token bucket ishlatadi (aniqroq — fixed window'ning chegara muammosi yo'q). Algoritm tanlovi ehtiyojga bog'liq: token bucket (API — burst ruxsat, lekin o'rtacha cheklangan — ko'p ishlatiladi), sliding window (aniq cheklash). Amaliyotda — kutubxona (Upstash, express-rate-limit) algoritmni boshqaradi (siz limit va oynani beragiz). Algoritmni tushunish — to'g'ri sozlash uchun (masalan burst kerakmi — token bucket).

2.3. Rate limit darajalari

text

  RATE LIMIT DARAJALARI — nima bo'yicha cheklash (kalit):

  1. IP BO'YICHA (eng keng — anonim foydalanuvchi):
   bir IP — daqiqada N so'rov (brute force, scraping)
   NAT/proxy: ko'p odam bir IP (ofis); IPv6 osongina o'zgaradi

  2. FOYDALANUVCHI BO'YICHA (autentifikatsiyalgan):
   bir foydalanuvchi — N so'rov (hisob darajasida — aniqroq)

  3. API KALIT BO'YICHA (API mijozlari — 14.6):
   har API kalit — kvota (tarif rejasiga qarab — free/premium)

  4. ENDPOINT BO'YICHA (har endpoint har xil limit):
   login: 5/daqiqa (qattiq); umumiy API: 100/daqiqa; qidiruv: 30/daqiqa

  5. GLOBAL (butun server — DoS himoyasi):
   umumiy so'rov chegarasi (server yuki)

  KOMBINATSIYA: IP + endpoint + foydalanuvchi (qatlamli)
   login: 5/daqiqa har IP; API: 100/daqiqa har foydalanuvchi

   Darajalar — IP (anonim), foydalanuvchi (auth), API kalit (kvota), endpoint (har xil)
   Login qattiq (5/daqiqa), umumiy yumshoqroq (100/daqiqa); kombinatsiya afzal

Rate limit darajalari — nima bo'yicha cheklash (kalit). Rate limit turli "kalit" bo'yicha: (1) IP bo'yicha (eng keng — anonim foydalanuvchi uchun): bir IP daqiqada N so'rov (brute force, scraping); kamchilik — NAT/proxy (ofis, universitet — ko'p odam bir IP'dan — adolatsiz bloklash mumkin), IPv6 osongina o'zgaradi (hujumchi ko'p IP); (2) foydalanuvchi bo'yicha (autentifikatsiyalgan — login qilgan): bir foydalanuvchi N so'rov (hisob darajasida — aniqroq, IP muammolariz); (3) API kalit bo'yicha (API mijozlari — 14.6): har API kalit — kvota (tarif rejasiga qarab — free 100/kun, premium 10000/kun); (4) endpoint bo'yicha (har endpoint har xil limit): login 5/daqiqa (qattiq — brute force), umumiy API 100/daqiqa (yumshoqroq), qidiruv 30/daqiqa (o'rta — resurs-og'ir); (5) global (butun server — DoS himoyasi): umumiy so'rov chegarasi (server yukini himoya). Kombinatsiya (qatlamli — afzal): IP + endpoint + foydalanuvchi (masalan login — 5/daqiqa har IP va har email; API — 100/daqiqa har foydalanuvchi). Ikki nuqta: (1) darajalar — IP (anonim), foydalanuvchi (auth — aniqroq), API kalit (kvota — tarif), endpoint (har xil limit), global (DoS); (2) login qattiq (5/daqiqa — brute force), umumiy yumshoqroq (100/daqiqa), kombinatsiya afzal (qatlamli — biri chetlab o'tilsa boshqasi). To'g'ri daraja — endpoint xususiyatiga qarab (login — qattiq, statik — yumshoq) va kalit (anonim — IP, auth — foydalanuvchi). IP-only rate limit zaif (NAT, IPv6) — foydalanuvchi/endpoint bilan kombinatsiya kuchliroq. Rate limit darajasini to'g'ri tanlash — adolatli (haqiqiy foydalanuvchini bloklamaslik) va samarali (hujumni to'sish) himoya.

2.4. Amaliy sozlash (Redis, Upstash)

text

  RATE LIMIT — AMALIY SOZLASH (hisobchi qaerda saqlanadi):

  MUAMMO: rate limit hisobchisi qaerda?
   bitta server xotirada (Map) — oddiy, lekin: server reset  yo'qoladi;
    ko'p server (load balancer) — har server o'z hisobchisi (limit buziladi)

  YECHIM — MARKAZIY saqlash (Redis — 5.21):
   barcha server bir Redis'ga (umumiy hisobchi — to'g'ri limit)
   tez (xotirada), atomic (race condition yo'q)

  EXPRESS (express-rate-limit + Redis):
  import rateLimit from "express-rate-limit";
  const limiter = rateLimit({
    windowMs: 60 * 1000,   // 1 daqiqa
    max: 100,              // 100 so'rov
    store: redisStore,     // Redis (ko'p server uchun)
    standardHeaders: true, // RateLimit-* header'lar
  });
  app.use("/api/", limiter);

  NEXT.JS / EDGE (Upstash Ratelimit — serverless/edge uchun):
  import { Ratelimit } from "@upstash/ratelimit";
  const ratelimit = new Ratelimit({ redis, limiter: Ratelimit.slidingWindow(100, "1 m") });
  const { success } = await ratelimit.limit(ip);   // middleware'da

   Rate limit hisobchisi — markaziy (Redis/Upstash) — ko'p server uchun to'g'ri
   Express: express-rate-limit; Next.js/edge: Upstash Ratelimit (serverless mos)

Amaliy sozlash (Redis, Upstash) — rate limit'ni qaerda va qanday saqlash. Muammo: rate limit hisobchisi (har manba nechta so'rov yubordi) qaerda saqlanadi? Bitta server xotirada (Map — 14.5: Misol 2) — oddiy, lekin ikki muammo: (1) server qayta ishga tushsa — hisobchi yo'qoladi (rate limit reset — hujumchiga foyda); (2) ko'p server (load balancer — production'da bir necha nusxa) — har server o'z hisobchisi (foydalanuvchi turli serverga tushsa — har birida alohida hisob — limit buziladi — masalan 3 server × 100 = 300 so'rov). Yechim — markaziy saqlash (Redis — 5.21): barcha server bir Redis'ga ulanadi (umumiy hisobchi — to'g'ri limit — har serverga tushsa ham bir hisob); Redis tez (xotirada), atomic (bir vaqtda ikki so'rov — race condition yo'q — to'g'ri sanaydi). Express (express-rate-limit + Redis store): rateLimit({ windowMs: 60000, max: 100, store: redisStore }) (1 daqiqa, 100 so'rov, Redis'da — ko'p server uchun), app.use("/api/", limiter). Next.js/edge (@upstash/ratelimit — serverless/edge uchun — 13.6: 2.9): new Ratelimit({ redis, limiter: Ratelimit.slidingWindow(100, "1 m") }), await ratelimit.limit(ip) (middleware'da — success true/false). Upstash — serverless Redis (edge'da ishlaydi — Vercel middleware uchun mos — 13.6). Ikki nuqta: (1) rate limit hisobchisi — markaziy (Redis/Upstash) — ko'p server uchun to'g'ri (xotira — bitta server demo); (2) Express — express-rate-limit, Next.js/edge — Upstash Ratelimit (serverless mos). Production'da rate limit markaziy bo'lishi shart (xotira — ko'p serverda buziladi). Redis/Upstash — standart yechim (tez, atomic, umumiy). Bu — rate limit'ni real, ko'p-serverli ilovada to'g'ri ishlatish (14.5: Misol 2 — demo Map; bu — production Redis).

2.5. DoS va DDoS

text

  DoS / DDoS — serverni so'rov bilan to'ldirib ishdan chiqarish (Availability — CIA):

  DoS (Denial of Service):
   BIR manba serverni so'rov bilan to'ldiradi  haqiqiy foydalanuvchi kira olmaydi

  DDoS (Distributed DoS):
   KO'P manba (botnet — minglab buzilgan qurilma) bir vaqtda  kuchliroq
   rate limit (IP bo'yicha) yetarli emas (har IP oz, lekin minglab IP)

  TURLARI:
   Volumetric (hajm — tarmoqni to'ldirish)
   Protocol (SYN flood — ulanish resurslari)
   Application (L7 — qimmat endpoint'larni ko'p chaqirish)

  HIMOYA (qatlamli):
  1. CDN (Cloudflare, Vercel) — trafikni filtrlash (server'ga yetishdan oldin)
  2. WAF (Web Application Firewall) — yomon so'rovlarni bloklash
  3. Rate limiting (application — qimmat endpoint)
  4. Auto-scaling (yuk oshsa — server qo'shish) + caching (yuk kamaytirish)

   DoS — bir manba; DDoS — ko'p manba (botnet) — rate limit yolg'iz yetarli emas
   Himoya — CDN/WAF (tarmoq daraja) + rate limit (app) + scaling/cache (chidamlilik)

DoS va DDoS — serverni to'ldirib ishdan chiqarish (Availability — CIA — 14.1: 2.1). DoS (Denial of Service): bir manba serverni so'rov bilan to'ldiradi (qisqa vaqtda juda ko'p so'rov) server haddan tashqari yuklanadi haqiqiy foydalanuvchilar kira olmay qoladi (xizmat to'xtaydi — biznes zarari). DDoS (Distributed DoS): ko'p manba (botnet — hujumchi nazoratidagi minglab buzilgan qurilma — kompyuter, IoT) bir vaqtda hujum kuchliroq, to'sish qiyinroq; bu yerda rate limit (IP bo'yicha) yetarli emas (har IP oz so'rov yuboradi — limitdan past — lekin minglab IP birlashib katta yuk). Turlari: (1) volumetric (hajm — tarmoqni to'ldirish — gigabit trafik); (2) protocol (SYN flood — TCP ulanish resurslarini tugatish); (3) application (L7 — qimmat endpoint'larni — masalan qidiruv, hisobot — ko'p chaqirish — kam trafik, lekin server CPU/DB tugaydi). Himoya (qatlamli — bir vosita yetmaydi): (1) CDN (Cloudflare, Vercel, AWS CloudFront) — trafikni server'ga yetishdan oldin filtrlaydi (DDoS trafikni o'zida yutadi — eng muhim DDoS himoyasi); (2) WAF (Web Application Firewall) — yomon so'rovlarni (hujum naqshlari) bloklaydi; (3) rate limiting (application — qimmat endpoint'lar); (4) auto-scaling (yuk oshsa — avtomatik server qo'shish — 10.10) + caching (yuk kamaytirish — 13.7). Ikki nuqta: (1) DoS — bir manba, DDoS — ko'p manba (botnet) — rate limit yolg'iz yetarli emas (DDoS uchun — har IP past, lekin minglab); (2) himoya — CDN/WAF (tarmoq daraja — DDoS), rate limit (app — abuse/DoS), scaling/cache (chidamlilik). DDoS himoyasi asosan CDN (Cloudflare — bepul tier ham kuchli DDoS himoya beradi — trafikni filtrlaydi) — bu tarmoq darajasida (server'ga yetishdan oldin). Rate limiting — application daraja (qimmat endpoint, abuse), DDoS uchun yetarsiz (CDN kerak). Ko'p ilova CDN orqali (Vercel, Cloudflare) — DDoS himoyasi avtomatik (qisman). To'liq himoya — qatlamli (CDN + WAF + rate limit + scaling).

2.6. Boshqa abuse himoyasi va best practices

text

  BOSHQA ABUSE HIMOYASI va BEST PRACTICES:

  QO'SHIMCHA HIMOYALAR:
   CAPTCHA (bot emas — odam) — login/forma (ko'p urinishdan keyin — 14.5)
   Progressiv kechikish (har urinishda sekinroq — 14.5: Misol 2)
   Proof of work (mijoz hisoblash qilsin — bot uchun qimmat)
   Bot aniqlash (xulq tahlili — inson vs bot)

  RATE LIMIT BEST PRACTICES:
   Markaziy hisobchi (Redis/Upstash — 2.4)
   Endpoint bo'yicha (login qattiq, umumiy yumshoq — 2.3)
   429 + Retry-After (mijoz to'g'ri ishlov bersin — 2.1)
   RateLimit-* header'lar (mijozga qancha qoldi)
   Allowlist (ishonchli mijoz/IP — cheklamasin)
   Adolatli limit (haqiqiy foydalanuvchini bloklamaslik)
   Monitoring (rate limit hodisalari — hujum belgisi — 13.10)

   Qo'shimcha — CAPTCHA, progressiv kechikish, bot aniqlash (rate limit bilan)
   Best — markaziy + endpoint bo'yicha + 429/Retry-After + adolat + monitoring

Boshqa abuse himoyasi va best practices — rate limiting'ni to'ldiruvchi himoyalar va amaliyot. Qo'shimcha himoyalar (rate limit bilan birga): (1) CAPTCHA (bot emas — odam tekshiruvi — reCAPTCHA, hCaptcha): login/forma'da ko'p urinishdan keyin (14.5 — avtomatik botlarni to'sadi); (2) progressiv kechikish (har urinishda sekinroq javob — 14.5: Misol 2 — brute force sekinlashtirish); (3) proof of work (mijoz biror hisoblash qilsin — odam uchun sezilmas, bot uchun qimmat — ko'p so'rov yuborish qimmatlashadi); (4) bot aniqlash (xulq tahlili — sichqoncha harakati, yozish tezligi — inson vs bot — ilg'or). Rate limit best practices: (1) markaziy hisobchi (Redis/Upstash — ko'p server — 2.4); (2) endpoint bo'yicha (login qattiq, umumiy yumshoq — 2.3); (3) 429 + Retry-After (mijoz to'g'ri ishlov bersin — qachon qayta — 2.1); (4) RateLimit- header'lar* (RateLimit-Remaining — mijozga qancha so'rov qoldi — yaxshi API tajribasi); (5) allowlist (ishonchli mijoz/IP — masalan o'z monitoring, partner API — cheklamaslik); (6) adolatli limit (haqiqiy foydalanuvchini bloklamaslik — limit yetarli baland, lekin abuse'ni to'sadi); (7) monitoring (rate limit hodisalari — ko'p 429 — hujum belgisi — 13.10 — Sentry/log). Ikki nuqta: (1) qo'shimcha — CAPTCHA, progressiv kechikish, bot aniqlash (rate limit bilan — qatlamli); (2) best — markaziy + endpoint bo'yicha + 429/Retry-After + adolat + monitoring. Rate limiting — kuchli, lekin yagona emas (CAPTCHA — botlar, CDN — DDoS, auth — hisob himoyasi — birga). To'g'ri rate limit — adolat (haqiqiy foydalanuvchi erkin, abuse cheklangan), shaffof (429/Retry-After — mijoz biladi), va kuzatiladigan (monitoring — hujum aniqlash). Bu — so'rov hajmi himoyasining to'liq yondashuvi (rate limit + qo'shimcha + monitoring). 14-QISMning hujum himoyalarining oxirgi qismi (bir so'rov — XSS/injection; ko'p so'rov — rate limit/DoS).

2.7. NestJS rate limiting — @nestjs/throttler

text

  @nestjs/throttler — NestJS'ning rasmiy rate limit moduli 5.20-bob:

  SOZLASH (app module):
  ThrottlerModule.forRoot([{ ttl: 60000, limit: 100 }])   // 60s — 100 so'rov
  + APP_GUARD  ThrottlerGuard (global — barcha route)

  DEKORATOR (route/controller darajasida):
  @Throttle({ default: { ttl: 60000, limit: 5 } })   // bu route — 5/daqiqa (login)
  @SkipThrottle()                                     // bu route — cheklanmasin

  MARKAZIY (ko'p server — Redis storage):
  ThrottlerStorageRedisService (xotira o'rniga Redis — 2.4)

  JAVOB: limit oshsa  ThrottlerException  429 (avtomatik)

   NestJS — @nestjs/throttler (ThrottlerModule + ThrottlerGuard)
   @Throttle (route limit), @SkipThrottle (ozod), Redis storage (ko'p server)

NestJS rate limiting — @nestjs/throttler — NestJS backend uchun rasmiy rate limit moduli (5.20 — NestJS). Express'da express-rate-limit (2.4, Misol 1) middleware bilan, NestJS'da esa @nestjs/throttler guard bilan (NestJS arxitekturasiga mos — 5.20). Sozlash: ThrottlerModule.forRoot([{ ttl: 60000, limit: 100 }]) (app module'da — ttl millisekundda oyna, limit — shu oynadagi maksimal so'rov — 60 soniyada 100), so'ng APP_GUARD provayder orqali ThrottlerGuard global qo'yiladi (barcha route avtomatik cheklanadi). Dekoratorlar (route yoki controller darajasida moslash — 2.3 endpoint bo'yicha): @Throttle({ default: { ttl: 60000, limit: 5 } }) — shu route uchun maxsus limit (masalan login — 5/daqiqa qattiq — umumiy 100 o'rniga); @SkipThrottle() — shu route rate limit'dan ozod (masalan webhook, ichki endpoint — allowlist mantiqiga o'xshash — 2.6). Markaziy saqlash (ko'p server — 2.4): standart storage xotirada (bitta server — demo); production'da ThrottlerStorageRedisService bilan Redis'ga o'tkaziladi (barcha nusxa bir hisobchi — to'g'ri limit). Javob: limit oshsa, ThrottlerGuard avtomatik ThrottlerException tashlaydi 429 Too Many Requests (2.1 — sozlanmasa standart javob; moslash mumkin). Bir nechta nomlangan throttler ham bo'lishi mumkin (short/long — masalan 3/soniya va 100/daqiqa — burst va umumiy — 2.2 token bucket mantiqiga o'xshash). Ikki nuqta: (1) NestJS'da rate limit — @nestjs/throttler (ThrottlerModule.forRoot + global ThrottlerGuard); (2) @Throttle (route/controller limit — endpoint bo'yicha), @SkipThrottle (ozod), Redis storage (ko'p server uchun). Bu — NestJS backend'ning standart rate limit yechimi (Express'ning express-rate-limit ekvivalenti — bir tamoyil, framework'ga mos API).

2.8. Resurs himoyasi — payload, timeout, ulanish, pagination

text

  RESURS HIMOYASI — rate limit yolg'iz emas; so'rovNING RESURS sarfini cheklash:

  1. PAYLOAD HAJMI (body limit — DoS: katta body  xotira):
   express.json({ limit: "100kb" });   // 100kb'dan katta  413 rad
   default cheksiz body  1GB JSON yuborib xotira tugatish

  2. TIMEOUT (uzoq so'rov  resurs band):
   server.setTimeout / socket timeout (30s'dan uzun  uzish)
   slowloris: ataylab sekin so'rov yuborib ulanishlarni band qilish

  3. ULANISH LIMITI (bir IP — cheklangan parallel ulanish):
   nginx/proxy: limit_conn (bir IP — 10 parallel ulanish)

  4. PAGINATION MAJBURIY (cheksiz natija  DB/xotira DoS):
   GET /users?limit=20 (max 100); limit'siz "hammani" bermaslik

  5. GraphQL — QUERY DEPTH / COMPLEXITY LIMITI 8.17-bob:
   chuqur nested query (DoS)  depth limit (masalan 7) + complexity limit

  6. FILE UPLOAD LIMITI (hajm + tur — 14 fayl xavfsizligi):
   maxFileSize (masalan 5MB) + MIME/kengaytma tekshiruvi

   Rate limit — so'rov SONI; resurs himoyasi — har so'rovNING sarfi (hajm/vaqt)
   Body limit + timeout + pagination + GraphQL depth — application DoS himoyasi

Resurs himoyasi — payload, timeout, ulanish, pagination — rate limit so'rov sonini cheklaydi, lekin har so'rov qancha resurs sarflashini ham cheklash kerak (aks holda kam so'rov bilan ham DoS — application-daraja — 2.5). Asosiy choralar: (1) payload hajmi (body limit) — katta so'rov tanasi xotira tugatishi mumkin (hujumchi 1GB JSON yuboradi); Express'da express.json({ limit: "100kb" }) (100kb'dan katta body 413 Payload Too Large rad); default ko'pincha cheklangan, lekin ochiq qoldirilsa xavf; (2) timeout — uzoq davom etadigan so'rov ulanish/resursni band qiladi; server/socket timeout (masalan 30 soniyadan uzun bo'lsa uzish) qo'yiladi — bu slowloris hujumiga qarshi muhim (hujumchi ataylab sekin so'rov yuborib — header'larni bir baytdan — ulanishlarni ochiq va band tutadi, yangi ulanishga joy qolmaydi); (3) ulanish limiti — bir IP'dan parallel ulanishlar soni cheklanadi (nginx limit_conn — bir IP 10 parallel ulanish — slowloris/soket tugatishga qarshi); (4) pagination majburiy — cheksiz natija qaytarish (GET /users — million qator) DB va xotirani tugatadi; har ro'yxat endpoint limit bilan (masalan ?limit=20, server tomonda max 100 majburlanadi — "hammasini" bermaslik); (5) GraphQL query depth/complexity limiti (8.17 — GraphQL): GraphQL'da chuqur ichma-ich (nested) so'rov (user { posts { author { posts { ... } } } }) yoki og'ir maydonlar bir so'rov bilan katta yuk beradi — depth limit (masalan maksimal 7 daraja) va complexity limit (har maydonga "narx" — umumiy chegara) qo'yiladi (introspection'ni prod'da o'chirish ham); (6) file upload limiti (fayl yuklash xavfsizligi) — yuklanadigan fayl hajmi (maxFileSize — masalan 5MB) va turi (MIME/kengaytma tekshiruvi) cheklanadi (katta/ko'p fayl — disk/xotira DoS). Ikki nuqta: (1) rate limit so'rov sonini cheklaydi, resurs himoyasi esa har so'rovning sarfini (hajm, vaqt, murakkablik) — ikkalasi kerak; (2) body limit + timeout + ulanish limiti + majburiy pagination + GraphQL depth/complexity + upload limit — bular birga application-daraja DoS himoyasini to'ldiradi 2.5-bob. Xulosa: so'rov sonini rate limit, har so'rovning og'irligini resurs limitlari to'sadi — ikkalasisiz application DoS ochiq qoladi (kam, lekin og'ir so'rov serverni tugatadi).

2.9. DDoS hujum turlari va tarmoq himoyasi (chuqur)

text

  DDoS HUJUM TURLARI (chuqurroq — 2.5 davomi):

  VOLUMETRIC (hajm — tarmoq kanalini to'ldirish, Gbps):
   UDP flood, ICMP flood — xom trafik bilan bandwidth tugatish

  PROTOCOL (protokol resurslari — tarmoq stack):
   SYN flood: TCP handshake'ni chala qoldirish (SYN yuborib, ACK yubormaslik)
     server yarim-ochiq ulanishlar bilan to'ladi (SYN cookies — himoya)

  AMPLIFICATION (kuchaytirish — kichik so'rov  katta javob):
   DNS/NTP amplification: soxta IP (qurbon) bilan kichik so'rov 
    server qurbonga KATTA javob (10-100x)  qurbonni bosadi

  APPLICATION (L7 — 2.5, 2.8):
   HTTP flood, slowloris, qimmat endpoint — kam trafik, katta ta'sir

  TARMOQ HIMOYASI:
   CDN + Anycast (bir IP — ko'p geografik nuqta — hujum tarqaladi/yutiladi)
   WAF (L7 filtr — hujum naqshlari)
   Autoscaling (yuk oshsa server qo'shish — 10-QISM) + caching
   Edge rate limit (server'ga yetishdan oldin — 2.4 Upstash edge)

   Turlari — volumetric (hajm), protocol (SYN flood), amplification (DNS/NTP), L7 (app)
   Himoya — CDN/Anycast + WAF (tarmoq); autoscaling/cache (chidamlilik); edge limit

DDoS hujum turlari va tarmoq himoyasi (chuqur) — 2.5'ning davomi, hujum turlarini va tarmoq-daraja himoyani chuqurroq ochadi. Turlari: (1) volumetric (hajmiy) — xom trafik bilan tarmoq kanalini (bandwidth) to'ldirish (UDP flood, ICMP flood — gigabit/terabit oqim); serverga so'rov qayta ishlashga ham navbat yetmaydi (kanal band); (2) protocol (protokol) — tarmoq stack resurslarini tugatish; klassik SYN flood: TCP uch bosqichli qo'l berish (handshake — SYN SYN-ACK ACK) ataylab chala qoldiriladi (hujumchi SYN yuboradi, oxirgi ACK'ni yubormaydi) server "yarim-ochiq" ulanishlar bilan to'ladi, yangi ulanishga joy qolmaydi; himoya — SYN cookies (server holatni saqlamaydi, ACK kelganda tiklaydi); (3) amplification (kuchaytirish) — kichik so'rov katta javob qaytaradigan xizmatdan (DNS, NTP, memcached) foydalanish: hujumchi soxta manba IP (qurbonning IP'si) bilan kichik so'rov yuboradi xizmat qurbonga o'nlab-yuzlab marta katta javob yuboradi qurbon o'z so'rovi bo'lmagan katta trafik ostida qoladi (reflection/amplification); (4) application (L7) — 2.5 va 2.8'da ko'rilgan (HTTP flood, slowloris, qimmat endpoint) — kam trafik, katta ta'sir. Tarmoq himoyasi: (1) CDN + Anycast — bir xil IP dunyo bo'ylab ko'p nuqtada e'lon qilinadi (Anycast), hujum trafigi eng yaqin nuqtalarga tarqaladi va yutiladi (bir markazga to'planmaydi — CDN quvvati katta — Cloudflare, AWS Shield); (2) WAF — L7 filtri (hujum naqshlari, yomon so'rovlar bloklanadi — application hujumlar); (3) autoscaling (yuk oshsa avtomatik server qo'shish — 10-QISM) + caching (statik/tez-tez javoblarni kesh — origin yukini kamaytirish — 13.7); (4) edge rate limit — CDN/edge darajasida (server'ga yetishdan oldin — 2.4 Upstash edge middleware) — hujumni chekkada to'sish. Ikki nuqta: (1) turlari — volumetric (hajm/bandwidth), protocol (SYN flood — yarim-ochiq ulanish), amplification (DNS/NTP — soxta IP bilan kuchaytirish), L7 (application); (2) himoya qatlamli — CDN/Anycast + WAF (tarmoq/edge — DDoS trafigini yutish), autoscaling/caching (chidamlilik), edge rate limit (chekkada to'sish). Volumetric/protocol/amplification himoyasi asosan infratuzilma darajasida (CDN/tarmoq provayderi — Cloudflare, AWS Shield) — ilova kodi bilan to'sib bo'lmaydi; ilova esa L7 (rate limit, resurs limitlari — 2.8) darajasini himoyalaydi. To'liq DDoS himoyasi — ilova + infratuzilma birgalikda.

2.10. Chidamlilik — circuit breaker, backpressure, graceful degradation, idempotency

text

  CHIDAMLILIK NAQSHLARI (yuk/nosozlikda tizim qulamasin):

  CIRCUIT BREAKER (9.6 — "avtomat o'chirgich"):
   tashqi xizmat/DB javob bermay/sekinlasa  chaqiruvni VAQTINCHA to'xtat
    (OPEN holat)  kaskad qulashni oldini oladi; keyin sinab ko'radi (HALF-OPEN)

  BACKPRESSURE (orqaga bosim):
   navbat/buffer to'lsa  yangi ishni RAD/sekinlashtir (429/503)
     tizim o'z quvvatidan ortiq ish olmasin (queue cheksiz o'smasin)

  GRACEFUL DEGRADATION (bosqichma-bosqich pasayish):
   yuk oshsa  ikkinchi darajali funksiyani o'chir (tavsiya, analitika)
     asosiy funksiya (to'lov, login) ishlashda qolsin

  IDEMPOTENCY (takroriy so'rov — 8.20):
   Idempotency-Key: bir kalitli takror so'rov  BIR marta bajariladi
     retry/tarmoq takrorida ikki marta to'lov/buyurtma bo'lmasin

   Circuit breaker (kaskad qulashni to'sish); backpressure (quvvatdan ortiq olmaslik)
   Graceful degradation (asosiy tirik qolsin); idempotency (takror xavfsiz)

Chidamlilik — circuit breaker, backpressure, graceful degradation, idempotency — rate limit tashqi hujumni to'sadi; bu naqshlar esa yuk yoki nosozlik ostida tizimning butunlay qulamasligini ta'minlaydi (chidamlilik — resilience). (1) Circuit breaker ("avtomat o'chirgich" — 9.6): tashqi xizmat yoki DB javob bermay/sekinlashsa, unga chaqiruvni vaqtincha to'xtatish (OPEN holat — darhol xato qaytariladi, kutmasdan) — bu kaskad qulashni (bir sekin xizmat butun tizimni bloklashini — barcha ulanish unga kutib qotishini) oldini oladi; ma'lum vaqtdan keyin ehtiyotkorlik bilan sinab ko'radi (HALF-OPEN tuzalsa CLOSED); (2) backpressure (orqaga bosim): ish navbati/buffer to'lganda tizim yangi ishni rad etadi yoki sekinlashtiradi (429/503) — o'z quvvatidan ortiq ish olib navbat cheksiz o'sib xotira tugatishining oldini oladi (rate limit — tashqi manbaga; backpressure — ichki quvvatga qarab); (3) graceful degradation (bosqichma-bosqich pasayish): yuk oshganda ikkinchi darajali funksiyalarni (tavsiyalar, analitika, boy tafsilotlar) vaqtincha o'chirib, asosiy funksiyalar (to'lov, login, buyurtma) ishlashda qolishini ta'minlash (butunlay o'chishdan ko'ra qisman xizmat yaxshiroq); (4) idempotency (takroriy so'rov — 8.20): mijoz tarmoq uzilishi yoki retry sabab bir xil so'rovni ikki marta yuborishi mumkin; Idempotency-Key header bilan server bir kalitli takror so'rovni bir marta bajaradi (ikkinchisiga saqlangan natijani qaytaradi) — ayniqsa to'lov/buyurtmada muhim (ikki marta yechilmasin). Ikki nuqta: (1) circuit breaker — sekin/nosoz tashqi xizmat sabab kaskad qulashni to'sadi, backpressure — tizim o'z quvvatidan ortiq ish olmasligini ta'minlaydi; (2) graceful degradation — yuk ostida asosiy funksiya tirik qoladi, idempotency — takroriy so'rov xavfsiz (ikki marta bajarilmaydi). Bular rate limit bilan birgalikda ishlaydi: rate limit tashqi so'rov hajmini chekkada to'sadi, chidamlilik naqshlari esa o'tib ketgan yuk yoki ichki nosozlik ostida tizimni tik ushlab turadi (himoya + chidamlilik — barqaror xizmat).

3. Sintaksis — tez ma'lumotnoma

text

RATE LIMIT 2.1-bob:   bir manba/vaqt — N so'rov; oshsa  429 + Retry-After
ALGORITM 2.2-bob:     sliding window (aniq) | token bucket (burst)
DARAJA 2.3-bob:       IP | foydalanuvchi | API kalit | endpoint (login qattiq)
EXPRESS 2.4-bob:      rateLimit({ windowMs, max, store: redis })
NEXT/EDGE 2.4-bob:    Ratelimit.slidingWindow(100, "1 m"); await limit(ip)
DDoS 2.5-bob:         CDN (Cloudflare/Vercel) + WAF + rate limit + scaling
QO'SHIMCHA 2.6-bob:   CAPTCHA, progressiv kechikish, monitoring
NESTJS 2.7-bob:       ThrottlerModule.forRoot([{ttl,limit}]); @Throttle/@SkipThrottle
RESURS 2.8-bob:       body limit + timeout + pagination + GraphQL depth + upload limit
DDoS TUR 2.9-bob:     volumetric | protocol(SYN) | amplification(DNS/NTP) | L7 | Anycast
CHIDAMLILIK 2.10-bob: circuit breaker | backpressure | graceful degradation | idempotency

4. Batafsil misollar

Har misol: Maqsad + izohli kod + "Bu nima qiladi".

Misol 1 — Express rate limit (Redis — 2.4)

Maqsad: Express API'ga rate limit qo'shish — Redis bilan (ko'p server uchun). Bu API'ni abuse va brute force'dan himoyalaydi.

tsx

import rateLimit from "express-rate-limit";
import { RedisStore } from "rate-limit-redis";
import { createClient } from "redis";

const redisClient = createClient({ url: process.env.REDIS_URL });
await redisClient.connect();

// UMUMIY API limit (har IP — daqiqada 100):
const apiLimiter = rateLimit({
  windowMs: 60 * 1000,        // 1 daqiqa
  max: 100,                   // 100 so'rov
  store: new RedisStore({ sendCommand: (...args) => redisClient.sendCommand(args) }),
  standardHeaders: true,      // RateLimit-* header'lar (mijozga qancha qoldi)
  message: { error: "Juda ko'p so'rov. Keyinroq urining." },   // 429 javob
});

// LOGIN limit (QATTIQROQ — brute force — 5/daqiqa — 14.5):
const loginLimiter = rateLimit({
  windowMs: 60 * 1000,
  max: 5,                     // faqat 5 (brute force)
  skipSuccessfulRequests: true,   // muvaffaqiyatli login sanalmaydi (faqat noto'g'ri)
  store: new RedisStore({ sendCommand: (...args) => redisClient.sendCommand(args) }),
});

app.use("/api/", apiLimiter);          // umumiy
app.use("/api/login", loginLimiter);   // login (qattiqroq)

Bu nima qiladi: Bu — Express rate limit (Redis bilan — 2.4). Ikki limit (endpoint bo'yicha — 2.3): (1) umumiy API (apiLimiter) — har IP daqiqada 100 so'rov (windowMs: 60000, max: 100), RedisStore (hisobchi Redis'da — ko'p server uchun to'g'ri — 2.4), standardHeaders (RateLimit-* header'lar — mijozga qancha so'rov qoldi — yaxshi API tajribasi), message (429 javobda — "Juda ko'p so'rov"); (2) login (loginLimiter) — qattiqroq (faqat 5/daqiqa — brute force himoyasi — 14.5), skipSuccessfulRequests: true (muvaffaqiyatli login sanalmaydi — faqat noto'g'ri urinishlar — haqiqiy foydalanuvchi ko'p marta to'g'ri kirsa bloklanmaydi, faqat noto'g'ri parol sinash cheklanadi — adolatli). app.use bilan: umumiy API'ga apiLimiter, login'ga loginLimiter (qattiqroq). Nega ikki limit (endpoint bo'yicha — 2.3): har endpoint xavfi har xil — login (brute force — qattiq, 5), umumiy API (abuse — yumshoqroq, 100); bir xil limit (hammaga 100) login'ni yetarli himoyalamaydi (100 marta parol sinash mumkin). Redis 2.4-bob — hisobchi markaziy (ko'p server — load balancer — har server bir Redis — to'g'ri limit; xotira bo'lsa — har server alohida — buziladi). skipSuccessfulRequests — nozik, lekin muhim (login limit faqat noto'g'ri urinishlarni sanaydi — haqiqiy foydalanuvchi erkin, hujumchi cheklangan). Bu — Express API'ning standart rate limit (umumiy + login + Redis). express-rate-limit algoritmni (sliding window) boshqaradi (siz limit beragiz). Production'da Redis majburiy (xotira — demo). Bu — API'ni so'rov hajmidan himoyalashning amaliy usuli.

Misol 2 — Next.js middleware rate limit (Upstash — 2.4)

Maqsad: Next.js'da edge middleware bilan rate limit — Upstash. Bu serverless/edge uchun mos (Vercel).

tsx

// middleware.ts — edge rate limit (Upstash):
import { Ratelimit } from "@upstash/ratelimit";
import { Redis } from "@upstash/redis";
import { NextResponse } from "next/server";

const ratelimit = new Ratelimit({
  redis: Redis.fromEnv(),                          // Upstash Redis (env'dan)
  limiter: Ratelimit.slidingWindow(100, "1 m"),    // sliding window — 100/daqiqa (2.2)
  analytics: true,
});

export async function middleware(request: NextRequest) {
  // IP bo'yicha (yoki auth bo'lsa — foydalanuvchi ID):
  const ip = request.headers.get("x-forwarded-for") ?? "anonim";

  const { success, limit, remaining, reset } = await ratelimit.limit(ip);

  if (!success) {
    // 429 + Retry-After 2.1-bob:
    return new NextResponse(JSON.stringify({ error: "Juda ko'p so'rov" }), {
      status: 429,
      headers: {
        "Retry-After": String(Math.ceil((reset - Date.now()) / 1000)),
        "RateLimit-Limit": String(limit),
        "RateLimit-Remaining": String(remaining),
      },
    });
  }

  return NextResponse.next();
}

export const config = { matcher: "/api/:path*" };   // faqat API (13.6: 2.8)

Bu nima qiladi: Bu — Next.js edge rate limit (Upstash — serverless/edge mos — 2.4). Vercel serverless/edge'da (13.6: 2.9) oddiy Redis qiyin (uzun ulanish) — Upstash (serverless Redis — HTTP orqali — edge'da ishlaydi) mos. Ratelimit sozlash: Redis.fromEnv() (Upstash env'dan), Ratelimit.slidingWindow(100, "1 m") (sliding window algoritm — 2.2 — aniq, 100/daqiqa), analytics (rate limit statistikasi). Middleware (13.6 — har so'rov sahifaga yetishdan oldin): (1) IP'ni olish (x-forwarded-for — yoki auth bo'lsa foydalanuvchi ID — 2.3); (2) ratelimit.limit(ip) — success (ruxsatmi), limit/remaining/reset (limit ma'lumotlari); (3) agar !success (limit oshgan) — 429 javob + header'lar: Retry-After (qachon qayta — 2.1), RateLimit-Limit/RateLimit-Remaining (mijozga qancha qoldi — 2.6); (4) aks holda next() (davom). matcher: "/api/:path*" (faqat API — 13.6: 2.8 — statik fayllarga rate limit keraksiz). Nega Upstash edge'da: Vercel middleware edge runtimeda ishlaydi (13.6: 2.9 — foydalanuvchiga yaqin, tez), va oddiy Redis (TCP ulanish) edge'da ishlamaydi — Upstash HTTP-asosli Redis (edge'da ishlaydi). Bu Next.js'ning standart rate limit naqshi (middleware + Upstash — markaziy, edge, serverless). 429 + Retry-After + RateLimit header'lar (2.1, 2.6 — to'g'ri mijoz tajribasi). Edge'da rate limit — foydalanuvchiga yaqin (tez to'sish) va markaziy (Upstash — ko'p edge nuqta bir hisobchi). Bu — zamonaviy serverless ilova uchun rate limit (Vercel + Upstash — keng kombinatsiya).

Maqsad: Login'ni ko'p qatlamli himoyalash — IP rate limit + hisob lockout + CAPTCHA. Bu brute force'ni samarali to'sadi (14.5 davomi).

tsx

async function login(email: string, password: string, ip: string) {
  // 1. IP RATE LIMIT (Upstash — daqiqada 10 urinish har IP):
  const ipLimit = await ipRatelimit.limit(`login:${ip}`);
  if (!ipLimit.success) {
    return { error: "Juda ko'p urinish (IP). Keyinroq urining.", status: 429 };
  }

  // 2. HISOB LOCKOUT (har email — 5 noto'g'ri  vaqtincha blok):
  const accountKey = `login-fail:${email}`;
  const fails = Number(await redis.get(accountKey)) || 0;
  if (fails >= 5) {
    return { error: "Hisob vaqtincha bloklangan. 15 daqiqadan keyin urining.", status: 429 };
  }

  // 3. CAPTCHA (3+ noto'g'ridan keyin — bot emas):
  // if (fails >= 3) require CAPTCHA tekshiruvi

  // 4. Parol tekshir (bcrypt — 14.5):
  const user = await db.user.findUnique({ where: { email } });
  const valid = user && (await bcrypt.compare(password, user.passwordHash));

  if (!valid) {
    // Noto'g'ri — hisobni oshir (15 daqiqa muddat):
    await redis.set(accountKey, fails + 1, { EX: 15 * 60 });
    return { error: "Email yoki parol noto'g'ri", status: 401 };   // bir xil javob (14.5: 2.7)
  }

  // To'g'ri — fail hisobni tozala:
  await redis.del(accountKey);
  return { user };
}

Bu nima qiladi: Bu — login'ni ko'p qatlamli brute force himoyasi (rate limit + lockout + CAPTCHA — 2.3, 14.5 davomi). To'rt qatlam (defense in depth — 14.1: 2.3): (1) IP rate limit (Upstash — har IP daqiqada 10 urinish — bir IP'dan ko'p urinishni cheklaydi — bot/scanner); (2) hisob lockout (har email — 5 noto'g'ri urinishdan keyin 15 daqiqa blok — Redis'da login-fail:email hisobchi, EX: 15*60 — 15 daqiqa muddat) — bu IP rate limit'ni to'ldiradi (hujumchi ko'p IP ishlatsa ham — bir email 5 urinishdan keyin bloklangan); (3) CAPTCHA (3+ noto'g'ridan keyin — bot emasligi tekshiriladi — avtomatik botlarni to'sadi); (4) parol tekshir (bcrypt — 14.5: Misol 1), noto'g'ri bo'lsa hisobni oshiradi + bir xil javob ("Email yoki parol noto'g'ri" — user enumeration oldini — 14.5: 2.7), to'g'ri bo'lsa fail hisobni tozalaydi. Nega ko'p qatlam: faqat IP rate limit — hujumchi ko'p IP (botnet, proxy) bilan chetlab o'tadi; faqat hisob lockout — DoS uchun ishlatilishi mumkin (hujumchi boshqalarni ataylab bloklaydi) — shuning uchun kombinatsiya (IP + hisob + CAPTCHA): IP rate limit (bir IP'dan scanning), hisob lockout (bir hisobga ko'p urinish — IP'dan qat'i nazar), CAPTCHA (bot). Bu qatlamlar birga brute force'ni samarali to'sadi (biri chetlab o'tilsa — boshqasi). Bir xil javob (14.5: 2.7) — har holda (qaysi qatlam yoki parol xato — enumeration oldini). Bu — login'ning to'liq, production himoyasi (14.5: Misol 2 demo'sining markaziy — Redis — va ko'p qatlamli versiyasi). Login — eng muhim, eng ko'p hujum qilinadigan endpoint (brute force, credential stuffing) — shuning uchun ko'p qatlamli himoya. Rate limit + lockout + CAPTCHA + bcrypt + 2FA 14.5-bob — birga login'ni mustahkam qiladi.

Misol 4 — Qimmat endpoint himoyasi (2.3, 2.5)

Maqsad: Resurs-og'ir endpoint'ni (qidiruv, AI, hisobot) qattiqroq cheklash — application DoS himoyasi. Bu qimmat operatsiyalarni suiiste'moldan saqlaydi.

tsx

// Resurs-og'ir endpoint'lar — QATTIQROQ limit (CPU/DB/pul):

// 1. AI endpoint (har so'rov pul — OpenAI token):
const aiLimit = Ratelimit.slidingWindow(10, "1 m");   // 10/daqiqa (qimmat)
const aiDailyLimit = Ratelimit.slidingWindow(100, "1 d");   // 100/kun (pul nazorati)

// 2. Qidiruv (DB-og'ir):
const searchLimit = Ratelimit.slidingWindow(30, "1 m");

// 3. Hisobot/eksport (CPU-og'ir):
const reportLimit = Ratelimit.slidingWindow(5, "1 h");   // 5/soat

async function aiEndpoint(userId: string, prompt: string) {
  // Ikki limit: daqiqa + kun (burst va umumiy — 2.2):
  const minute = await aiLimit.limit(`ai:${userId}`);
  const daily = await aiDailyLimit.limit(`ai-daily:${userId}`);
  if (!minute.success || !daily.success) {
    return { error: "AI limiti tugadi. Tarifni oshiring yoki keyinroq.", status: 429 };
  }
  // ... qimmat AI so'rov (faqat limit ichida)
}

Bu nima qiladi: Bu — qimmat endpoint himoyasi (application DoS — 2.3, 2.5). Ba'zi endpoint'lar resurs-og'ir (CPU, DB, yoki to'g'ridan pul — AI tokenlar, tashqi API) — bular qattiqroq cheklanishi kerak (umumiy 100/daqiqa emas — kamroq). Misollar: (1) AI endpoint (har so'rov OpenAI token — pul) — 10/daqiqa (burst) va 100/kun (umumiy pul nazorati) — ikki limit (daqiqa — qisqa portlash, kun — umumiy xarajat — 2.2); (2) qidiruv (DB-og'ir — murakkab so'rov) — 30/daqiqa; (3) hisobot/eksport (CPU-og'ir — katta hisoblash) — 5/soat (juda qattiq — kam, lekin og'ir). aiEndpointda ikki limit tekshiriladi (daqiqa + kun) — biri ham tugasa rad ("AI limiti tugadi"). Nega qattiqroq: (1) application DoS (2.5 — L7 hujum) — hujumchi qimmat endpoint'ni (qidiruv, hisobot) ko'p chaqirib serverni tugatadi (kam so'rov, lekin har biri og'ir — CPU/DB tugaydi) — umumiy rate limit yetarsiz (qimmat endpoint maxsus cheklov kerak); (2) pul nazorati — AI/tashqi API har so'rov pul — rate limit'siz bot minglab so'rov katta hisob (kunlik limit — xarajat shifti); (3) adolat — qimmat resurs (AI) bir foydalanuvchi tomonidan tugatilmasin. Demak: endpoint xarajatiga qarab limit (oddiy — yumshoq, qimmat — qattiq, AI — daqiqa + kun + tarif). Bu application-daraja DoS himoyasi (network DoS — CDN — 2.5; application DoS — qimmat endpoint rate limit). Ko'p ilova umumiy rate limit qo'yadi, lekin qimmat endpoint'larni (AI, hisobot, eksport) maxsus cheklamaydi — bu xavf (server tugaydi yoki katta hisob). To'g'ri — har endpoint xarajatiga mos limit (qimmat — qattiqroq, pul — kunlik kvota). Bu — resurs va xarajatni himoyalashning amaliy usuli (ayniqsa AI/tashqi API davrida muhim — har so'rov pul).

Misol 5 — Rate limit monitoring va sozlash (2.6)

Maqsad: Rate limit hodisalarini kuzatish va to'g'ri sozlash — hujum aniqlash va adolatli limit. Bu rate limit'ni samarali va adolatli qiladi.

tsx

// Rate limit hodisasi — log + monitoring (hujum belgisi — 2.6):
async function checkRateLimit(key: string, ip: string) {
  const { success, remaining, limit } = await ratelimit.limit(key);

  if (!success) {
    //  Ko'p 429 — hujum belgisi (monitoring — 13.10):
    logger.warn("Rate limit oshdi", { key, ip, limit });
    metrics.increment("rate_limit.exceeded", { endpoint: key });
    // Agar bir IP juda ko'p marta limit oshsa — uzoqroq blok / alert
  }
  return success;
}

// ALLOWLIST — ishonchli mijoz (cheklamasin):
const ALLOWLIST = new Set(["monitoring-service-ip", "partner-api-key"]);
function isAllowlisted(identifier: string) {
  return ALLOWLIST.has(identifier);   // o'z monitoring/partner — rate limit'siz
}

text

RATE LIMIT SOZLASH PRINSIPLARI 2.6-bob:
 ADOLAT — limit haqiqiy foydalanuvchi ehtiyojidan YUQORI
  (oddiy foydalanuvchi hech qachon yetmasin; faqat abuse/hujum yetsin)
 ENDPOINT BO'YICHA — login 5, API 100, AI 10 (xarajatga mos — 2.3, Misol 4)
 MONITORING — ko'p 429  hujum/noto'g'ri limit (tekshir)
 ALLOWLIST — ishonchli (monitoring, partner) cheklanmasin
 SHAFFOF — 429 + Retry-After + RateLimit-* (mijoz biladi — 2.1)

Bu nima qiladi: Bu — rate limit monitoring va to'g'ri sozlash (samarali va adolatli himoya — 2.6). Monitoring (checkRateLimit): rate limit oshganda (!success) — log (logger.warn — kim, qaysi endpoint) va metrics (metrics.increment — rate limit hodisalari soni — 13.10 monitoring). Nega: ko'p 429 (rate limit oshishi) — hujum belgisi (kimdir ko'p so'rov yuboryapti — brute force, scraping, DoS) — monitoring buni aniqlaydi (agar bir IP juda ko'p marta limit oshsa — uzoqroq blok yoki alert — proaktiv himoya); yoki noto'g'ri limit belgisi (haqiqiy foydalanuvchilar ham 429 olayapti — limit juda past — adolatsiz — oshirish kerak). Allowlist (isAllowlisted): ishonchli mijozlar (o'z monitoring xizmati, partner API — 14.6) rate limit'dan ozod (ular ko'p so'rov yuborishi normal — cheklash noto'g'ri). Sozlash prinsiplari: (1) adolat — limit haqiqiy foydalanuvchi ehtiyojidan yuqori (oddiy foydalanuvchi hech qachon yetmasin — masalan odam daqiqada 100 API so'rov yubormaydi — faqat bot/hujum yetadi; agar limit juda past bo'lsa — haqiqiy foydalanuvchi bloklanadi — yomon); (2) endpoint bo'yicha (login 5, API 100, AI 10 — xarajatga mos — 2.3, Misol 4); (3) monitoring (ko'p 429 — hujum yoki noto'g'ri limit — tekshir); (4) allowlist (ishonchli cheklanmasin); (5) shaffof (429 + Retry-After + RateLimit-* — mijoz qancha qoldi/qachon qayta — biladi — 2.1, 2.6). Bu prinsiplar rate limit'ni samarali (hujumni to'sadi) va adolatli (haqiqiy foydalanuvchini bloklamaydi) qiladi. Eng keng xato — limit juda past (haqiqiy foydalanuvchilar bloklanadi — yomon UX) yoki juda baland (abuse o'tadi). To'g'ri — adolat (foydalanuvchi ehtiyojidan yuqori, abuse'dan past) + monitoring (sozlamani tekshir) + allowlist (ishonchli). Rate limit — balans (juda qattiq — foydalanuvchiga zarar; juda yumshoq — himoya yo'q). Monitoring bu balansni topishga yordam beradi (real ma'lumot — kim 429 oladi). Bu — rate limit'ni professional ishlatish (faqat qo'yish emas — kuzatish, sozlash, adolat).

Misol 6 — NestJS rate limiting — @nestjs/throttler (2.7)

Maqsad: NestJS backend'ga rate limit qo'shish — global limit + endpoint bo'yicha moslash + Redis storage. Bu NestJS'ning rasmiy, arxitekturaga mos rate limit yechimi 5.20-bob.

tsx

// app.module.ts — global throttler (Redis storage — ko'p server):
import { ThrottlerModule, ThrottlerGuard } from "@nestjs/throttler";
import { ThrottlerStorageRedisService } from "@nest-lab/throttler-storage-redis";
import { APP_GUARD } from "@nestjs/core";

@Module({
  imports: [
    ThrottlerModule.forRoot({
      throttlers: [
        { name: "short", ttl: 1000, limit: 3 },      // 1s — 3 (burst — 2.2)
        { name: "long", ttl: 60_000, limit: 100 },   // 60s — 100 (umumiy)
      ],
      storage: new ThrottlerStorageRedisService(process.env.REDIS_URL),  // markaziy (2.4)
    }),
  ],
  providers: [
    { provide: APP_GUARD, useClass: ThrottlerGuard },  // global — barcha route
  ],
})
export class AppModule {}

// auth.controller.ts — endpoint bo'yicha moslash 2.3-bob:
import { Throttle, SkipThrottle } from "@nestjs/throttler";

@Controller("auth")
export class AuthController {
  @Throttle({ default: { ttl: 60_000, limit: 5 } })   // login — QATTIQ (5/daqiqa — brute force)
  @Post("login")
  login() { /* ... */ }

  @SkipThrottle()                                      // ichki webhook — cheklanmasin (allowlist — 2.6)
  @Post("internal-webhook")
  webhook() { /* ... */ }
}

Bu nima qiladi: Bu — NestJS'ning rasmiy rate limit moduli @nestjs/throttler (2.7 — Express'dagi express-rate-limitning NestJS ekvivalenti). Global sozlash (app.module.ts): ThrottlerModule.forRoot bilan ikkita nomlangan throttler — short (1 soniyada 3 so'rov — burst nazorati — 2.2 token bucket mantiqi) va long (60 soniyada 100 — umumiy) — ikkalasi ham tekshiriladi (biri oshsa rad); storage: ThrottlerStorageRedisService (hisobchi Redis'da — ko'p server uchun to'g'ri — 2.4, xotira o'rniga); APP_GUARD orqali ThrottlerGuard global (barcha route avtomatik cheklanadi). Endpoint bo'yicha moslash (auth.controller.ts — 2.3): @Throttle({ default: { ttl: 60000, limit: 5 } }) login'ga — qattiqroq (5/daqiqa — brute force — 14.5); @SkipThrottle() ichki webhook'ka — rate limit'dan ozod (allowlist mantiqi — 2.6 — ishonchli/ichki manba). Limit oshsa, guard avtomatik ThrottlerException 429 Too Many Requests 2.1-bob. Nega guard (middleware emas): NestJS DI/guard arxitekturasiga mos (dekorator bilan deklarativ — controller/route darajasida — 5.20), tartib guard zanjirida boshqariladi. Bu — NestJS backend'ning standart rate limit naqshi (global default + @Throttle moslash + @SkipThrottle ozod + Redis markaziy) — Express'ning express-rate-limit (Misol 1) bilan bir tamoyil, framework'ga mos API.

Misol 7 — Resurs himoyasi va idempotency (2.8, 2.10)

Maqsad: So'rovlarning resurs sarfini cheklash (body, timeout, pagination) va takroriy so'rovni xavfsiz qilish (idempotency). Bu application DoS va takroriy to'lov muammosini oldini oladi.

tsx

import express from "express";
const app = express();

// 1. BODY HAJMI LIMITI (katta payload DoS — 2.8):
app.use(express.json({ limit: "100kb" }));   // 100kb'dan katta  413 Payload Too Large

// 2. SO'ROV TIMEOUT (uzoq/slowloris — 2.8):
app.use((req, res, next) => {
  res.setTimeout(30_000, () => {              // 30s'dan uzun  uzish
    res.status(503).json({ error: "So'rov vaqti tugadi" });
  });
  next();
});

// 3. PAGINATION MAJBURIY (cheksiz natija DoS — 2.8):
app.get("/api/users", async (req, res) => {
  const limit = Math.min(Number(req.query.limit) || 20, 100);   // maksimal 100 (cheksiz emas)
  const offset = Number(req.query.offset) || 0;
  const users = await db.user.findMany({ take: limit, skip: offset });
  res.json({ users, limit, offset });
});

// 4. IDEMPOTENCY (takroriy so'rov — to'lov ikki marta bo'lmasin — 2.10, 8.20):
app.post("/api/payment", async (req, res) => {
  const key = req.header("Idempotency-Key");
  if (!key) return res.status(400).json({ error: "Idempotency-Key kerak" });

  const cached = await redis.get(`idem:${key}`);
  if (cached) return res.json(JSON.parse(cached));   // takror  saqlangan natija (qayta bajarmaydi)

  const result = await processPayment(req.body);     // faqat BIR marta
  await redis.set(`idem:${key}`, JSON.stringify(result), { EX: 24 * 60 * 60 });
  res.json(result);
});

Bu nima qiladi: Bu — resurs himoyasi 2.8-bob va idempotency (2.10, 8.20) amaliyoti. Resurs himoyasi (rate limit so'rov sonini cheklaydi; bular har so'rovning sarfini): (1) body hajmi (express.json({ limit: "100kb" })) — 100kb'dan katta so'rov tanasi 413 rad (hujumchi gigabaytli JSON bilan xotira tugatishining oldi olinadi); (2) timeout (res.setTimeout(30000)) — 30 soniyadan uzun so'rov uziladi (slowloris — ataylab sekin so'rov bilan ulanish band qilishning oldi); (3) pagination majburiy — limitni serverda Math.min(..., 100) bilan cheklash (mijoz ?limit=999999 so'rasa ham maksimal 100 — cheksiz natija bilan DB/xotira DoS'ining oldi — "hammasini" bermaslik). Idempotency (2.10, 8.20): /api/paymentda mijoz Idempotency-Key (noyob kalit — masalan UUID) yuboradi; server avval Redis'da shu kalit borligini tekshiradi — bo'lsa saqlangan natijani qaytaradi (qayta bajarmaydi), bo'lmasa to'lovni bir marta bajaradi va natijani kalit bilan saqlaydi (EX: 24 soat). Nega: tarmoq uzilishi yoki mijoz retry sabab bir xil to'lov so'rovi ikki marta yetishi mumkin — idempotency'siz ikki marta pul yechiladi (jiddiy xato); kalit bilan takror so'rov xavfsiz (bir marta bajariladi). Nega birga: rate limit tashqi hujum hajmini, resurs limitlari har so'rovning og'irligini (application DoS — 2.5), idempotency esa takroriy so'rov to'g'riligini himoyalaydi — bularsiz "so'rov hajmi himoyasi" to'liq emas (rate limit yolg'iz kam, lekin og'ir yoki takroriy so'rovni to'smaydi). Bu — so'rov himoyasining rate limit'dan tashqari, resurs va to'g'rilik qatlamlari.

5. To'g'ri va noto'g'ri holatlar

1) Login

text

 rate limit yo'q (brute force — 2.1)
 IP + hisob lockout + CAPTCHA (Misol 3)

2) Hisobchi

text

 xotirada (ko'p server — buziladi — 2.4)
 Redis/Upstash (markaziy)

3) Limit darajasi

text

 hammaga bir xil (login = API)
 endpoint bo'yicha (login qattiq — 2.3, Misol 1)

4) Qimmat endpoint

text

 umumiy limit (AI/hisobot tugaydi — 2.5)
 qattiqroq + pul kvota (Misol 4)

5) DDoS

text

 faqat rate limit (botnet o'tadi — 2.5)
 CDN/WAF + rate limit (qatlamli)

6) Limit adolat

text

 juda past (haqiqiy foydalanuvchi bloklanadi)
 adolatli (ehtiyojdan yuqori, abuse'dan past — 2.6)

7) Resurs sarfi

text

 faqat so'rov soni cheklangan (katta body/cheksiz natija  DoS — 2.8)
 body limit + timeout + pagination + upload/GraphQL limit (Misol 7)

8) Takroriy so'rov

text

 idempotency yo'q (retry  ikki marta to'lov — 2.10)
 Idempotency-Key (bir marta bajariladi — Misol 7, 8.20)

6. Keng tarqalgan xatolar va yechimlari

Xato 1 — Login'da rate limit yo'q

Sababi: brute force ochiq 2.1-bob. Yechimi: IP + hisob + CAPTCHA (Misol 3).

Xato 2 — Hisobchi xotirada (ko'p server)

Sababi: har server alohida 2.4-bob. Yechimi: Redis/Upstash (Misol 1, 2).

Xato 3 — Bir xil limit (login = API)

Sababi: endpoint xavfi har xil 2.3-bob. Yechimi: endpoint bo'yicha (Misol 1).

Xato 4 — Qimmat endpoint himoyasiz

Sababi: AI/hisobot umumiy limit 2.5-bob. Yechimi: qattiqroq + kvota (Misol 4).

Xato 5 — DDoS'ga rate limit yetarli deb o'ylash

Sababi: botnet IP rate limit'ni o'tadi 2.5-bob. Yechimi: CDN/WAF (Cloudflare).

Xato 6 — Limit juda past (foydalanuvchi bloklanadi)

Sababi: adolatsiz 2.6-bob. Yechimi: monitoring + adolatli limit (Misol 5).

Xato 7 — Body/pagination limitsiz (resurs DoS)

Sababi: katta payload yoki cheksiz natija xotira/DB tugatadi 2.8-bob. Yechimi: body limit + timeout + majburiy pagination + upload/GraphQL depth limit (Misol 7).

Xato 8 — Idempotency yo'q (takroriy to'lov)

Sababi: retry/tarmoq takrorida so'rov ikki marta bajariladi 2.10-bob. Yechimi: Idempotency-Key (Misol 7, 8.20).

Xato 9 — Sekin tashqi xizmat butun tizimni bloklaydi

Sababi: circuit breaker yo'q — kaskad qulash 2.10-bob. Yechimi: circuit breaker + timeout + graceful degradation (9.6, 2.10).

7. Integratsiya — bu mavzu stack'ning qayerida uchraydi

Auth 14.5-bob: login brute force (rate limit).
Redis 5.21-bob: rate limit hisobchisi (markaziy).
Middleware 13.6-bob: Next.js edge rate limit (Upstash).
Backend 5.20-bob: express-rate-limit, @nestjs/throttler (NestJS — 2.7).
OWASP 14.1-bob: Availability (DoS — CIA).
DevOps (10-QISM): CDN, WAF, auto-scaling, Anycast (DDoS — 2.9).
Monitoring 13.10-bob: rate limit hodisalari (hujum aniqlash — 10.9 anomaliya).
API (5.7, 13.6): API kvota (tarif rejasi), pagination 2.8-bob.
GraphQL 8.17-bob: query depth/complexity limit 2.8-bob.
Chidamlilik 9.6-bob: circuit breaker, backpressure 2.10-bob.
Idempotency 8.20-bob: takroriy so'rov himoyasi 2.10-bob.

8. Eng yaxshi amaliyotlar (best practices)

Login rate limit (brute force — IP + hisob + CAPTCHA — Misol 3).
Markaziy hisobchi (Redis/Upstash — ko'p server — Misol 1, 2).
Endpoint bo'yicha (login qattiq, AI qattiqroq — 2.3, Misol 4).
429 + Retry-After + RateLimit-* (shaffof — 2.1, Misol 2).
CDN/WAF DDoS uchun (rate limit yetarli emas — 2.5).
Qimmat endpoint kvota (AI pul nazorati — Misol 4).
Adolatli limit (foydalanuvchini bloklamaslik — 2.6).
Monitoring (rate limit hodisalari — hujum — Misol 5).
Allowlist (ishonchli mijoz — Misol 5).
skipSuccessfulRequests (login — faqat noto'g'ri — Misol 1).
NestJS — @nestjs/throttler (ThrottlerGuard + @Throttle/@SkipThrottle — 2.7, Misol 6).
Resurs limitlari (body + timeout + majburiy pagination + upload/GraphQL depth — 2.8, Misol 7).
Idempotency (takroriy so'rov — Idempotency-Key — 2.10, Misol 7).
Chidamlilik (circuit breaker + backpressure + graceful degradation — 2.10, 9.6).

9. Amaliy loyiha: "Rate Limiting va DoS Himoyasi"

So'rov hajmi himoyasini mustahkamlash.

Maqsad

API'ni rate limit bilan himoyalang: login brute force, API abuse, qimmat endpoint, monitoring.

Talablar (requirements)

Markaziy: Redis/Upstash hisobchi (Misol 1, 2).
Login: IP + hisob lockout + CAPTCHA (Misol 3).
Endpoint bo'yicha: login qattiq, API yumshoq (Misol 1).
Qimmat endpoint: AI/hisobot kvota (Misol 4).
429 + Retry-After: to'g'ri javob (Misol 2).
DDoS: CDN (Cloudflare/Vercel — 2.5).
Monitoring: rate limit hodisalari (Misol 5).
Allowlist: ishonchli mijoz (Misol 5).
Adolat: limit ehtiyojdan yuqori 2.6-bob.
Resurs limitlari: body hajmi + timeout + majburiy pagination (2.8, Misol 7).
Idempotency: to'lov/buyurtma endpoint — Idempotency-Key (2.10, Misol 7).
Test: brute force, ko'p so'rov, katta payload, takroriy so'rov sinab ko'ring.

Maslahatlar (hint)

Markaziy Redis (Xato 2).
Login ko'p qatlam (Xato 1).
Endpoint bo'yicha (Xato 3).
CDN DDoS (Xato 5).
Adolatli (Xato 6).
Resurs limitlari — body/pagination (Xato 7).
Idempotency — to'lov (Xato 8).

"Tayyor" mezonlari (acceptance criteria)

Markaziy hisobchi (Redis).
Login brute force himoya.
Endpoint bo'yicha limit.
Qimmat endpoint kvota.
429 + Retry-After.
Monitoring + adolat.
Resurs limitlari (body + pagination).
Idempotency (to'lov endpoint).

Yechim kodi ataylab berilmagan — bu loyihani o'zingiz yozib ko'ring.

10. Xulosa va keyingi bobga ko'prik

Bu bobda rate limiting va DoS himoyasini chuqur o'rgandik:

Rate limiting 2.1-bob; algoritmlar (fixed/sliding window, token/leaky bucket — 2.2); darajalar (IP/foydalanuvchi/API kalit/endpoint/global — 2.3); sozlash (Redis/Upstash — 2.4); DoS/DDoS (turlari, CDN/WAF — 2.5); abuse/best practices 2.6-bob; NestJS throttler 2.7-bob; resurs himoyasi (body/timeout/pagination/GraphQL/upload — 2.8); DDoS turlari va tarmoq himoyasi (SYN flood, amplification, Anycast — 2.9); chidamlilik (circuit breaker, backpressure, graceful degradation, idempotency — 2.10).

Endi siz so'rov hajmidan himoyani qura olasiz: rate limiting (brute force, abuse — Express/NestJS/edge), markaziy hisobchi (Redis), endpoint bo'yicha, resurs limitlari (body/pagination), DDoS (CDN/WAF/Anycast), va chidamlilik (circuit breaker, idempotency). Bu — bir so'rov hujumlari (XSS/injection) qatorida ko'p so'rov hujumlari (DoS/abuse) himoyasi.

Keyingi bob — 14.9-bob: Xavfsizlik auditi va yakuniy amaliyot. 14-QISMni yakunlaymiz: barcha himoyani (OWASP Top 10, XSS, injection, CSRF/SSRF, auth, token, headers, rate limit) bitta xavfsizlik auditida birlashtiramiz — avtomatik vositalar (npm audit, SAST/DAST, dependency scanning), xavfsizlik checklisti, va xavfsiz ishlab chiqarish madaniyati. So'ng yakuniy xavfsizlik loyihasi (audit + tuzatish).

Foydalanilgan rasmiy/ishonchli manbalar

OWASP — "Denial of Service Cheat Sheet", "Blocking Brute Force Attacks", "REST Security Cheat Sheet"
OWASP — API Security Top 10 (API4:2023 — Unrestricted Resource Consumption), Availability (CIA)
express-rate-limit va rate-limit-redis; @upstash/ratelimit hujjatlari; Redis (rate limiting patterns — sliding window, token bucket)
@nestjs/throttler (NestJS rasmiy rate limit moduli) hujjatlari
MDN — 429 Too Many Requests, Retry-After, RateLimit / RateLimit-Policy header'lar; 413 Payload Too Large
Cloudflare — DDoS himoya, WAF, Anycast; AWS — Shield / WAF (DDoS best practices)
IETF — draft "RateLimit header fields for HTTP"; SYN cookies (RFC 4987 — TCP SYN flooding)
Stripe — Idempotency (Idempotency-Key) va rate limit hujjatlari (idempotent API)
Nginx — limit_req / limit_conn (rate va connection limiting); circuit breaker naqshi (Martin Fowler)

Izohlar (0)

Izoh yozish uchun kiring.

Hozircha izoh yo'q. Birinchi bo'ling!

14.8-bob: Rate limiting va DoS himoyasi

1. Kirish va motivatsiya

2. Nazariya — chuqur tushuntirish

2.1. Rate limiting nima va nega

2.2. Rate limiting algoritmlari

2.3. Rate limit darajalari

2.4. Amaliy sozlash (Redis, Upstash)

2.5. DoS va DDoS

2.6. Boshqa abuse himoyasi va best practices

2.7. NestJS rate limiting — @nestjs/throttler

2.8. Resurs himoyasi — payload, timeout, ulanish, pagination

2.9. DDoS hujum turlari va tarmoq himoyasi (chuqur)

2.10. Chidamlilik — circuit breaker, backpressure, graceful degradation, idempotency

3. Sintaksis — tez ma'lumotnoma

4. Batafsil misollar

Misol 1 — Express rate limit (Redis — 2.4)

Misol 2 — Next.js middleware rate limit (Upstash — 2.4)

Misol 3 — Login brute force himoyasi (rate limit + lockout — 2.3)

Misol 4 — Qimmat endpoint himoyasi (2.3, 2.5)

Misol 5 — Rate limit monitoring va sozlash (2.6)

Misol 6 — NestJS rate limiting — @nestjs/throttler (2.7)

Misol 7 — Resurs himoyasi va idempotency (2.8, 2.10)

5. To'g'ri va noto'g'ri holatlar

6. Keng tarqalgan xatolar va yechimlari

7. Integratsiya — bu mavzu stack'ning qayerida uchraydi

8. Eng yaxshi amaliyotlar (best practices)

9. Amaliy loyiha: "Rate Limiting va DoS Himoyasi"

Maqsad

Talablar (requirements)

Maslahatlar (hint)

"Tayyor" mezonlari (acceptance criteria)

10. Xulosa va keyingi bobga ko'prik

Foydalanilgan rasmiy/ishonchli manbalar

Izohlar (0)