Rate Limiting چیست؟ چرا محدودسازی درخواست‌ها برای امنیت سایت ضروری است؟

پاسخ کوتاه: Rate Limiting یا محدودسازی نرخ درخواست، مکانیزمی است که مشخص می‌کند یک کاربر، IP، حساب، API Key، Device یا Client در یک بازه زمانی چند درخواست می‌تواند به سایت یا API ارسال کند. این کنترل برای مقابله با Brute Force، Credential Stuffing، حملات Bot، سوءاستفاده از API، Spam، Scraping و مصرف بیش از حد منابع سرور ضروری است.

هر درخواست HTTP که به یک وب‌سایت یا API ارسال می‌شود برای سرور هزینه دارد.

حتی یک درخواست ساده ممکن است باعث اجرای چند مرحله شود:

اتصال به Reverse Proxy،

اجرای WAF،

بررسی Session،

اجرای PHP یا Node.js،

Query پایگاه داده،

خواندن Cache،

ارسال Email،

تماس با API خارجی،

محاسبه نتیجه،

و در نهایت ارسال Response.

اگر یک کاربر واقعی چند درخواست در دقیقه ارسال کند، این مصرف منابع معمولاً مشکلی ایجاد نمی‌کند.

اما چه اتفاقی می‌افتد اگر یک Bot در همان مدت ده‌ها هزار درخواست ارسال کند؟

یا اگر مهاجم روی صفحه Login هر ثانیه صدها Password امتحان کند؟

یا Endpoint ارسال OTP هزاران بار فراخوانی شود؟

یا API تبدیل تصویر، تولید PDF، ارسال SMS یا هوش مصنوعی بدون محدودیت در اختیار Client قرار داشته باشد؟

در این شرایط حتی اگر هیچ آسیب‌پذیری کلاسیکی مانند SQL Injection یا XSS وجود نداشته باشد، خود قابلیت قانونی برنامه می‌تواند علیه زیرساخت استفاده شود.

اینجاست که Rate Limiting اهمیت پیدا می‌کند.

Rate Limiting یکی از کنترل‌های بنیادی امنیت Application و API است که تعیین می‌کند هر Client در چه محدوده‌ای اجازه تعامل با سیستم را دارد.

OWASP در API Security Top 10، مصرف بدون محدودیت منابع را یک ریسک جدی معرفی می‌کند و توضیح می‌دهد درخواست‌های API می‌توانند منابعی مانند CPU، RAM، Bandwidth و Storage را مصرف کنند یا حتی هزینه‌هایی در سرویس‌های ثالث مانند Email، SMS و پردازش ابری ایجاد کنند. اعمال محدودیت بر تعداد تعاملات Client با API یکی از کنترل‌های اصلی پیشنهادی OWASP است.

اما Rate Limiting فقط یک عدد مانند «100 درخواست در دقیقه» نیست.

یک طراحی حرفه‌ای باید مشخص کند:

چه چیزی محدود می‌شود؟

Client چگونه شناسایی می‌شود؟

محدودیت برای چه Endpointی است؟

چه زمانی Counter ریست می‌شود؟

آیا Burst مجاز است؟

در صورت عبور از Limit چه اتفاقی می‌افتد؟

آیا درخواست Reject می‌شود یا Delay؟

آیا Limit برای User و IP هم‌زمان اعمال می‌شود؟

در معماری توزیع‌شده Counter کجا ذخیره می‌شود؟

و چگونه بدون آسیب زدن به کاربران واقعی جلوی Abuse گرفته می‌شود؟

در این مقاله از رخنه‌کاو، Rate Limiting را از دید امنیتی و معماری بررسی می‌کنیم و می‌بینیم چرا تقریباً هر سایت، API و Application مدرن به نوعی از محدودسازی درخواست نیاز دارد.

Rate Limiting چیست؟

Rate Limiting مکانیزمی است برای کنترل تعداد یا سرعت عملیات‌هایی که یک Client در یک بازه زمانی مشخص می‌تواند انجام دهد.

یک Policy بسیار ساده ممکن است بگوید:

حداکثر 100 درخواست
در مدت 60 ثانیه
برای هر IP

یا:

حداکثر 5 تلاش ورود
در مدت 10 دقیقه
برای هر حساب

یا:

حداکثر 3 درخواست ارسال OTP
در مدت 15 دقیقه
برای هر شماره تلفن

هدف محدودسازی این نیست که کاربران واقعی را متوقف کند.

هدف این است که رفتار غیرطبیعی، خودکار یا پرهزینه نتواند بدون کنترل ادامه پیدا کند.

Rate Limiting می‌تواند در لایه‌های مختلف اعمال شود:

CDN،

Load Balancer،

WAF،

Reverse Proxy،

API Gateway،

Application،

Database،

یا حتی سرویس‌های Third-Party.

در معماری‌های حرفه‌ای معمولاً چند لایه Rate Limiting هم‌زمان وجود دارد.

برای مثال:

Internet
↓
CDN Rate Limit
↓
WAF Bot Rules
↓
Reverse Proxy Limit
↓
Application Rate Limit
↓
Business-Level Quota

هر لایه وظیفه متفاوتی دارد.

چرا Rate Limiting برای امنیت سایت مهم است؟

بدون Rate Limiting، Application عملاً به Client اجازه می‌دهد تعداد نامحدودی Request ایجاد کند.

اگر هر Request ارزان باشد شاید در نگاه اول مشکلی دیده نشود، اما درخواست‌ها در مقیاس بالا می‌توانند منابع سرور را مصرف کنند.

برای مثال هر Login ممکن است شامل Password Hash Verification باشد.

Password Hashing عمداً باید نسبتاً پرهزینه باشد تا Cracking دشوار شود.

حال اگر هزاران Login Request هم‌زمان دریافت شود، CPU سرور ممکن است تحت فشار قرار گیرد.

در Endpoint دیگری، هر Request ممکن است SMS واقعی ارسال کند.

در این حالت حمله فقط CPU مصرف نمی‌کند؛ هزینه مالی مستقیم ایجاد می‌کند.

OWASP در API4:2023 توضیح می‌دهد که عدم محدودسازی منابع نه‌تنها می‌تواند باعث Denial of Service شود، بلکه ممکن است هزینه‌های زیرساختی یا هزینه استفاده از سرویس‌های ثالث را نیز افزایش دهد.

بنابراین Rate Limiting هم:

کنترل امنیتی،

کنترل Availability،

کنترل Abuse،

و گاهی کنترل هزینه

است.

تفاوت Rate Limiting و Throttling

Rate Limiting و Throttling اغلب به جای یکدیگر استفاده می‌شوند، اما می‌توان میان آن‌ها تفاوت مفهومی قائل شد.

Rate Limiting

Rate Limiting معمولاً یک سقف تعیین می‌کند.

مثلاً:

60 درخواست در دقیقه

پس از عبور از سقف ممکن است Request Reject شود.

Throttling

در Throttling سیستم می‌تواند سرعت درخواست‌ها را کاهش دهد.

مثلاً Client درخواست‌های زیادی ارسال می‌کند اما Server آن‌ها را با سرعت کنترل‌شده پردازش می‌کند.

به جای:

Reject

ممکن است:

Delay
Queue
Slow down

انجام شود.

در عمل بسیاری از Productها و مستندات این دو اصطلاح را به‌صورت نزدیک به هم استفاده می‌کنند.

از دید امنیتی مهم‌تر از نام این است که سیستم بتواند نرخ مصرف Resource را کنترل کند.

تفاوت Rate Limit و Quota

Quota معمولاً سقف مصرف در بازه‌ای طولانی‌تر است.

مثلاً:

10000 Request در ماه

این مدل در APIهای تجاری بسیار رایج است.

Rate Limit ممکن است:

10 Request در ثانیه

باشد.

پس یک Client ممکن است هرگز Rate Limit لحظه‌ای را رد نکند اما Quota ماهانه‌اش تمام شود.

برای مثال:

Rate Limit:
10 requests / second

Daily Quota:
50,000 requests / day

ترکیب این دو هم از Burst ناگهانی جلوگیری می‌کند و هم مصرف کلی را کنترل می‌کند.

تفاوت Rate Limiting و Connection Limiting

Rate Limiting تعداد Request را کنترل می‌کند.

Connection Limit تعداد Connectionهای هم‌زمان را محدود می‌کند.

برای مثال در WebSocket، محدود کردن تعداد پیام در ثانیه به تنهایی کافی نیست.

ممکن است مهاجم هزاران Connection باز کند و هیچ Message زیادی نفرستد.

بنابراین می‌توان هم‌زمان داشت:

Max connections per account = 5

Max messages per second = 20

در APIهای معمول HTTP نیز محدودیت Concurrent Request اهمیت دارد.

یک Client ممکن است فقط 100 Request داشته باشد اما همه را دقیقاً هم‌زمان ارسال کند.

Concurrency Limit می‌تواند جلوی اشغال Workerها و Connection Pool را بگیرد.

چه حملاتی با Rate Limiting کاهش پیدا می‌کنند؟

Rate Limiting راهکار تمام حملات نیست، اما در کاهش بسیاری از حملات Automated نقش مهمی دارد.

Brute Force

در Brute Force مهاجم تعداد زیادی Password را برای پیدا کردن Credential صحیح امتحان می‌کند.

اگر Login Endpoint هیچ محدودیتی نداشته باشد، مهاجم می‌تواند تعداد Attempt بسیار زیادی انجام دهد.

Rate Limiting تعداد Guess در واحد زمان را کاهش می‌دهد.

Credential Stuffing

در Credential Stuffing مهاجم Credentialهای افشاشده واقعی را روی تعداد زیادی Account آزمایش می‌کند.

در اینجا فقط Limit براساس Account کافی نیست، زیرا ممکن است هر Account تنها یک Attempt دریافت کند.

باید الگوهای:

Accounts per IP
IPs per account
Device
ASN
Velocity

نیز بررسی شوند.

OWASP نیز هشدار می‌دهد که Credential Stuffing می‌تواند از Proxy Networkهای توزیع‌شده استفاده کند و Rate Limit صرفاً مبتنی بر IP را دور بزند.

Password Spraying

در Password Spraying یک Password رایج روی تعداد زیادی User امتحان می‌شود.

Rate Limit per-account به تنهایی ممکن است این Attack را نبیند.

محدودیت per-IP یا Source Behaviour کمک بیشتری می‌کند.

OTP Abuse

Endpoint ارسال OTP بسیار حساس است.

بدون Limit، مهاجم می‌تواند:

SMS Flooding،

هزینه مالی،

مزاحمت برای User

یا تلاش برای حدس OTP

ایجاد کند.

Forgot Password Abuse

درخواست بازیابی Password باید محدود شود.

در غیر این صورت Bot می‌تواند هزاران Reset Email برای User ارسال کند.

Registration Spam

ساخت Account خودکار می‌تواند:

Database را پر کند،

Email Verification ایجاد کند،

Referral System را Abuse کند،

یا Promotional Credit مصرف کند.

Comment Spam

فرم نظر، Review، Forum یا Chat بدون Rate Limiting می‌تواند هدف Botها باشد.

Scraping

Rate Limiting نمی‌تواند تمام Scraping را متوقف کند، اما می‌تواند هزینه جمع‌آوری خودکار داده را افزایش دهد.

API Abuse

Client ممکن است Endpoint پرهزینه را بسیار بیشتر از رفتار طبیعی فراخوانی کند.

Denial of Service

Rate Limiting برای DDoS بزرگ کافی نیست، اما می‌تواند از بسیاری از Application-Layer DoSها جلوگیری کند یا اثر آن‌ها را کاهش دهد.

Rate Limiting جای DDoS Protection را نمی‌گیرد

یکی از اشتباهات رایج این است که گفته شود:

«Rate Limit داریم، پس DDoS حل شده است.»

خیر.

اگر Traffic عظیمی قبل از رسیدن به Rate Limiter ظرفیت Network Link یا Load Balancer را پر کند، Application دیگر فرصتی برای Reject کردن Request ندارد.

برای حملات حجیم به:

CDN،

Anycast Network،

DDoS Protection،

Upstream Filtering

و زیرساخت مناسب نیاز است.

Rate Limiting بیشتر برای کنترل رفتار Client در Application Layer اهمیت دارد.

Rate Limit باید روی چه چیزی اعمال شود؟

یکی از اصلی‌ترین تصمیم‌ها انتخاب Key است.

Rate Limit Counter باید به یک Identity یا Dimension متصل شود.

IP Address

ساده‌ترین روش:

rate-limit:<ip>

مزایا:

قبل از Authentication در دسترس است.

پیاده‌سازی ساده است.

برای Botهای ساده مؤثر است.

اما مشکلاتی دارد.

صدها User ممکن است پشت یک NAT مشترک باشند.

مثلاً:

شرکت،

دانشگاه،

اپراتور موبایل،

VPN

ممکن است یک Public IP مشترک داشته باشند.

اگر یکی از کاربران رفتار غیرعادی داشته باشد، Block کردن IP می‌تواند همه را تحت تأثیر قرار دهد.

از طرف دیگر Attacker می‌تواند IP خود را تغییر دهد.

بنابراین IP باید Signal باشد، نه Identity قطعی.

Rate Limit بر اساس User Account

بعد از Authentication می‌توان Counter را به User ID متصل کرد.

rate-limit:user:1234

مزیت آن این است که تغییر IP باعث Reset شدن Limit نمی‌شود.

برای Endpointهایی مانند:

Generate Report،

Create API Key،

Upload،

Transfer،

AI Generation

بسیار مفید است.

اما Login قبل از Authentication است.

در آنجا Username یا Account Candidate می‌تواند Key دوم باشد.

Per-Username Rate Limit

در Login بهتر است تلاش روی هر Account محدود شود.

مثلاً:

حداکثر 5 Failure
برای یک username
در 10 دقیقه

این کنترل جلوی Targeted Brute Force توزیع‌شده را می‌گیرد.

حتی اگر مهاجم از 1000 IP استفاده کند، همه Attemptها روی همان Account Counter جمع می‌شوند.

اما فقط per-username نیز کافی نیست.

مهاجم Credential Stuffing می‌تواند از یک IP هزاران Username مختلف را امتحان کند.

بنابراین باید حداقل دو Limit مستقل داشته باشیم:

Per Account
+
Per Source

OWASP Bot Management Cheat Sheet نیز برای Login دو Bucket مستقل per-username و per-IP را توصیه می‌کند؛ ترکیب IP و Username در یک Bucket واحد می‌تواند باعث شود مهاجم برای هر Pair یک سهمیه تازه به دست آورد.

Rate Limit بر اساس API Key

برای APIهای عمومی یا Partner API معمولاً بهترین Identity یک API Key یا Client ID است.

مثلاً:

API Key Basic:
100 req/min

API Key Pro:
1000 req/min

این مدل برای:

Billing،

Quota،

Abuse Detection

و Service Tier

مناسب است.

اما Rate Limit per-IP همچنان می‌تواند به‌عنوان لایه مکمل باقی بماند.

Rate Limit بر اساس Device

Device ID یا Device Fingerprint می‌تواند Signal دیگری باشد.

اما Fingerprint قطعی نیست.

Client می‌تواند بعضی Attributeها را تغییر دهد.

Privacy نیز باید در نظر گرفته شود.

Device Fingerprint بهتر است به‌عنوان Signal Risk استفاده شود، نه اینکه تنها مکانیزم شناسایی باشد.

Multi-Dimensional Rate Limiting

در سیستم واقعی بهترین مدل معمولاً ترکیب چند Limit است.

مثلاً Login:

20 requests/minute per IP
5 failures/10 minutes per account
100 requests/hour per device
500 requests/hour per ASN when suspicious

برای Reset Password:

3 reset requests/hour per account
20 requests/hour per IP

برای OTP:

3 sends/15 min per phone
10 sends/hour per account
20 sends/hour per IP
5 verify failures per challenge

هر Request باید از همه Policyهای مرتبط عبور کند.

Rate Limit را برای همه Endpointها یکسان نکنید

صفحه Home و Endpoint ارسال SMS هزینه یکسانی ندارند.

بنابراین Policy:

100 requests/minute for everything

طراحی ضعیفی است.

Endpointها باید براساس Risk و Cost طبقه‌بندی شوند.

Endpoint کم‌هزینه

مثلاً:

GET /public/status

ممکن است Limit بالاتری داشته باشد.

Endpoint Authentication

POST /login

باید Limit سخت‌گیرانه‌تری داشته باشد.

Endpoint مالی

POST /withdraw

ممکن است علاوه بر Rate Limiting به Transaction Limit نیز نیاز داشته باشد.

Endpoint بسیار پرهزینه

مثلاً:

POST /generate-video
POST /export-report
POST /send-sms

باید براساس Cost واقعی محدود شود.

OWASP نیز تأکید می‌کند Rate Limiting باید براساس Business Requirement هر API تنظیم شود و بعضی Endpointها نیازمند Policy سخت‌گیرانه‌تر هستند.

الگوریتم Fixed Window

ساده‌ترین الگوریتم:

Window = 12:00 تا 12:01
Limit = 100

Counter در شروع Window صفر می‌شود.

پیاده‌سازی آسان است.

اما مشکل Boundary دارد.

Client می‌تواند:

100 Request در 12:00:59
+
100 Request در 12:01:01

ارسال کند.

در فاصله دو ثانیه عملاً 200 Request پذیرفته شده، در حالی که Policy ظاهراً 100 Request در دقیقه بوده است.

به همین دلیل Fixed Window برای بعضی Endpointهای حساس مناسب‌ترین گزینه نیست.

Sliding Window

Sliding Window به جای بازه‌های ثابت، تاریخچه نزدیک به زمان فعلی را بررسی می‌کند.

اگر اکنون 12:01:20 باشد، سیستم ممکن است Requestهای بازه:

12:00:20
تا
12:01:20

را حساب کند.

مزیت:

Boundary Burst کمتر می‌شود.

عیب:

پیاده‌سازی و Storage می‌تواند پیچیده‌تر باشد.

Sliding Window Log دقیق ممکن است Timestamp هر Request را نگه دارد.

برای سیستم بسیار پرترافیک این کار هزینه دارد.

روش‌های Approximation برای کاهش Cost وجود دارند.

Token Bucket

Token Bucket یکی از الگوریتم‌های بسیار کاربردی است.

تصور کنید Bucket ظرفیت 20 Token دارد.

هر Request یک Token مصرف می‌کند.

Tokenها با سرعت مشخص دوباره تولید می‌شوند.

مثلاً:

Capacity = 20
Refill = 5 token/second

اگر User مدتی Request نداشته باشد، Bucket پر می‌شود و می‌تواند یک Burst محدود ایجاد کند.

بعد از مصرف Tokenها باید منتظر Refill بماند.

این مدل برای APIهایی که Burst کوتاه طبیعی دارند مناسب است.

مثلاً Browser ممکن است هنگام Load صفحه چند Request هم‌زمان ایجاد کند.

Leaky Bucket

Leaky Bucket را می‌توان مانند سطلی تصور کرد که Request وارد آن می‌شود اما خروجی با سرعت ثابتی انجام می‌شود.

اگر ورودی بیش از ظرفیت Bucket شود، Request اضافی Reject می‌شود.

NGINX برای limit_req از مدل Leaky Bucket استفاده می‌کند و می‌تواند Burst محدودی را نیز مدیریت کند.

مزیت این روش Smooth کردن Traffic است.

کدام الگوریتم بهتر است؟

هیچ پاسخ جهانی وجود ندارد.

Fixed Window:

ساده و ارزان.

Sliding Window:

دقیق‌تر برای محدودیت واقعی در هر بازه زمانی.

Token Bucket:

مناسب Burst کنترل‌شده.

Leaky Bucket:

مناسب Smooth کردن جریان.

انتخاب به نوع Endpoint و رفتار طبیعی کاربران بستگی دارد.

Burst چیست؟

همه Burstها حمله نیستند.

فرض کنید User صفحه Dashboard را باز می‌کند.

Browser ممکن است هم‌زمان درخواست‌های زیر را بفرستد:

/profile
/notifications
/stats
/messages
/preferences

اگر Limit دقیقاً:

1 req/sec

باشد، Application تجربه بسیار بدی خواهد داشت.

به همین دلیل بعضی Policyها اجازه Burst محدود می‌دهند.

مثلاً:

Average: 5 req/sec
Burst: 20

یعنی Client می‌تواند برای مدت کوتاهی سریع‌تر Request ارسال کند، اما نرخ طولانی‌مدت محدود باقی می‌ماند.

HTTP 429 Too Many Requests

وقتی Client Rate Limit را رد می‌کند، HTTP Status استاندارد مرتبط:

429 Too Many Requests

است.

RFC 6585 کد 429 را برای شرایطی تعریف کرده که User در یک مدت زمانی تعداد بیش از حد Request ارسال کرده است. Response می‌تواند توضیح وضعیت را ارائه کند و می‌تواند Header Retry-After داشته باشد.

نمونه:

HTTP/1.1 429 Too Many Requests
Retry-After: 60
Content-Type: application/json

Response:

{
  "error": "Too many requests"
}

Retry-After چیست؟

Header:

Retry-After: 60

می‌گوید Client بهتر است حداقل 60 ثانیه صبر کند.

RFC 9110 مشخص می‌کند Retry-After می‌تواند یک Date یا تعداد ثانیه انتظار باشد.

مثلاً:

Retry-After: 120

یا:

Retry-After: Wed, 21 Oct 2026 07:28:00 GMT

برای Public API، این Header می‌تواند به Client قانونی کمک کند Backoff مناسبی انجام دهد.

اما در Endpointهای Authentication باید درباره میزان اطلاعاتی که به Attacker می‌دهید محتاط باشید.

آیا باید Remaining Limit را به Client نشان دهیم؟

در API Developer-Friendly ممکن است مفید باشد که Client بفهمد چه میزان Quota باقی مانده است.

اما در Security-Sensitive Endpoint مانند Login، نمایش جزئیات دقیق ممکن است به Automation کمک کند.

مثلاً اگر API بگوید:

3 تلاش باقی مانده
Reset دقیقاً در 43 ثانیه

Bot می‌تواند Timing خود را بهینه کند.

بنابراین میزان اطلاعات باید براساس Threat Model تعیین شود.

Rate Limiting در Login

Login یکی از مهم‌ترین Endpointهاست.

مدل ساده و ضعیف:

5 request/minute per IP

چرا ضعیف است؟

زیرا مهاجم می‌تواند IPها را تغییر دهد.

همچنین کاربران پشت NAT ممکن است به اشتباه محدود شوند.

طراحی بهتر:

Per-IP limit
+
Per-account limit
+
Long-term velocity
+
Device / ASN / reputation
+
Risk-based challenge

مثلاً پس از رفتار مشکوک:

Normal
↓
Delay
↓
CAPTCHA
↓
MFA challenge
↓
Temporary block

این Response تدریجی بهتر از Block دائمی سریع است.

Rate Limiting در Reset Password

Forgot Password باید هم per-account و هم per-source محدود شود.

هدف جلوگیری از:

Email Flooding،

User Harassment،

Automation

و هزینه‌های Email Provider

است.

اما Error Message باید عمومی باقی بماند.

حتی اگر Account وجود نداشته باشد، Response نباید تفاوتی ایجاد کند که User Enumeration ممکن شود.

Rate Limiting در OTP

OTP دو بخش دارد:

ارسال OTP

باید محدود شود تا User پیام زیاد دریافت نکند.

Verify OTP

باید محدود شود تا Code قابل Brute Force نباشد.

مثلاً یک Code شش‌رقمی تنها یک میلیون حالت دارد.

اگر Attempt نامحدود باشد، امنیت آن بسیار ضعیف می‌شود.

بنابراین:

OTP lifetime
+
Attempt limit
+
Rate limit
+
Single use

در کنار هم ضروری هستند.

Rate Limiting در Registration

Registration خودکار می‌تواند مشکلات زیادی ایجاد کند.

مثلاً یک Bot می‌تواند:

هزاران User بسازد،

Email Verification بفرستد،

Coupon دریافت کند،

Referral Reward بگیرد،

یا Database را پر کند.

Rate Limit باید روی:

IP،

Device،

Email Domain،

Phone Number

و رفتار کلی

قابل بررسی باشد.

Rate Limiting برای Search

Search Endpoint گاهی از Login نیز پرهزینه‌تر است.

مثلاً Query شامل:

Full-Text Search،

Database Join،

External Search Engine

یا AI Ranking

است.

اگر Search بدون Limit باشد، Bot می‌تواند CPU و Database را تحت فشار قرار دهد.

علاوه بر تعداد Request باید:

حداکثر Query Length،

Page Size،

Result Count،

Query Complexity

و Timeout

نیز محدود شوند.

Rate Limiting در GraphQL

GraphQL چالش خاصی دارد.

ممکن است یک HTTP Request حاوی Query بسیار پیچیده باشد.

بنابراین:

100 requests/min

به تنهایی کافی نیست.

یک Request ممکن است هزینه‌ای معادل صدها Query ساده داشته باشد.

باید علاوه بر Request Rate:

Query Depth،

Complexity،

Batch Size،

Aliases،

Number of Operations

محدود شوند.

OWASP نیز Batching و تعداد عملیات در یک Request را در بحث Unrestricted Resource Consumption جزو Limitهای مهم معرفی می‌کند.

Rate Limiting در WebSocket

WebSocket پس از Handshake یک Connection طولانی ایجاد می‌کند.

اگر Rate Limiter فقط HTTP Upgrade را ببیند:

GET /socket

اما Messageهای بعدی را محدود نکند، مهاجم می‌تواند Message Flooding انجام دهد.

بنابراین WebSocket نیازمند:

Connection Limit،

Messages per second،

Payload Size Limit،

Per-action Limit،

Idle Timeout،

Backpressure

است.

Rate Limiting و File Upload

ممکن است User فقط یک Request ارسال کند اما یک فایل 10GB آپلود کند.

پس Request Count به تنهایی Resource Limit نیست.

Upload باید:

Maximum File Size،

Concurrent Upload Limit،

Total Storage Quota،

Bandwidth Limit

داشته باشد.

Rate Limiting بخشی از کنترل Resource است، نه همه آن.

Rate Limiting و سرویس‌های AI

Endpointهای AI معمولاً هزینه‌بر هستند.

مثلاً:

Text Generation،

Image Generation،

Video Generation،

Speech,

OCR

ممکن است Cost مستقیم API یا GPU ایجاد کنند.

مدل مناسب ممکن است به جای Request ساده از Unit استفاده کند.

مثلاً:

Text model request = 1 credit
Image generation = 10 credits
Video generation = 100 credits

در این شرایط Rate Limit و Quota باید Cost-Aware باشند.

Weighted Rate Limiting

همه Requestها وزن یکسان ندارند.

مثلاً:

GET /profile = 1 unit
POST /search = 3 units
POST /export = 20 units

هر Client یک Bucket از Unitها دارد.

این مدل دقیق‌تر از Request Count خام است.

برای APIهای پیچیده و Cloud Serviceها Weighted Limit کاربرد زیادی دارد.

Cost-Based Limiting

یک مرحله پیشرفته‌تر این است که Cost واقعی Operation وارد Policy شود.

برای مثال:

Database rows scanned
CPU time
AI tokens
Storage bytes
External API cost

ممکن است Rate Limit بر اساس Usage Point تنظیم شود.

این مدل می‌تواند از Economic DoS جلوگیری کند.

Economic Denial of Service چیست؟

گاهی هدف مهاجم Down کردن سایت نیست.

هدف بالا بردن هزینه است.

مثلاً Endpoint زیر:

POST /send-sms

برای هر Call هزینه دارد.

هزاران Request ممکن است:

سرور را از دسترس خارج نکند،

اما قبض SMS بزرگی ایجاد کند.

OWASP صراحتاً هزینه سرویس‌های ثالث مانند SMS، Email، تماس یا پردازش را در Unrestricted Resource Consumption مطرح می‌کند.

راهکار:

Rate Limit،

Quota،

Spending Limit،

Billing Alert

و Business Rule.

معماری پیشنهادی Rate Limiting

یک معماری چندلایه:

Internet
↓
CDN / DDoS Protection
↓
WAF
↓
Edge Rate Limiting
↓
Reverse Proxy
↓
API Gateway
↓
Application Rate Limiting
↓
Business Quota
↓
Database / External Services

لایه Edge حملات حجیم ساده را متوقف می‌کند.

Application می‌تواند User Identity و Business Context را ببیند.

Business Layer می‌تواند Operationهای حساس را محدود کند.

هیچ‌کدام جای دیگری را نمی‌گیرد.

Rate Limiting در NGINX

NGINX ماژول رسمی ngx_http_limit_req_module را برای محدودسازی نرخ پردازش Request دارد و این محدودسازی را براساس Key تعریف‌شده، برای مثال IP Client، با روش Leaky Bucket انجام می‌دهد.

یک نمونه ساده دفاعی:

http {
    limit_req_zone $binary_remote_addr
                   zone=login_limit:10m
                   rate=5r/m;

    server {
        location /login {
            limit_req zone=login_limit burst=5 nodelay;

            proxy_pass http://backend;
        }
    }
}

این Config صرفاً نمونه مفهومی است.

مقادیر واقعی نباید Copy-Paste شوند.

باید براساس Traffic واقعی سایت تنظیم شوند.

چرا IP واقعی پشت Proxy مهم است؟

فرض کنید:

User
↓
Cloudflare
↓
NGINX

اگر NGINX همه Requestها را با IP Cloudflare ببیند، تمام کاربران یک Key خواهند داشت.

در نتیجه Rate Limit عملاً خراب می‌شود.

در مقابل اگر Application هر X-Forwarded-For دلخواه User را قبول کند، مهاجم می‌تواند IP خود را Spoof کند.

باید فقط Proxyهای مورد اعتماد اجازه تعیین Client IP داشته باشند.

Trust Proxy Configuration یکی از اجزای مهم Rate Limiting است.

Rate Limiting در معماری چند سروری

فرض کنید Application پنج Node دارد:

Load Balancer
├─ App 1
├─ App 2
├─ App 3
├─ App 4
└─ App 5

اگر هر Node Counter مستقل داشته باشد و Limit:

10 req/min

باشد، Client ممکن است با پخش Request میان پنج Node عملاً:

50 req/min

دریافت کند.

در معماری Distributed، Rate Limit State باید:

Centralized،

Shared،

یا Consistently Partitioned

باشد.

Redis یکی از گزینه‌های رایج برای Counterهای توزیع‌شده است.

اما خود Redis نیز باید:

High Availability،

Atomic Operation،

TTL

و Failure Policy

مناسب داشته باشد.

Race Condition در Rate Limiting

الگوی ناامن:

Read counter
if counter < limit
    increment
    allow

اگر چند Request هم‌زمان اجرا شوند، همه ممکن است Counter قدیمی را ببینند.

برای Rate Limiter باید Increment و Check تا حد امکان Atomic باشد.

در Redis معمولاً از Operationهای Atomic یا Script مناسب استفاده می‌شود.

این موضوع در سیستم پرترافیک اهمیت زیادی دارد.

اگر Rate Limiter از کار افتاد چه کنیم؟

یکی از تصمیم‌های معماری مهم:

Fail Open یا Fail Closed؟

فرض کنید Redis Rate Limiter Down شود.

Fail Open

Requestها ادامه پیدا می‌کنند.

مزیت:

Availability حفظ می‌شود.

عیب:

Abuse Control حذف می‌شود.

Fail Closed

Requestها Reject می‌شوند.

مزیت:

کنترل امنیتی حفظ می‌شود.

عیب:

خرابی Rate Limiter می‌تواند کل سایت را Down کند.

پاسخ به نوع Endpoint وابسته است.

برای صفحه عمومی ممکن است Fail Open منطقی باشد.

برای Endpoint مالی بسیار حساس شاید Fail Closed انتخاب مناسب‌تری باشد.

گاهی Hybrid Policy بهتر است.

Rate Limiting نباید تنها Defense Login باشد

Attacker می‌تواند Distributed باشد.

پس باید Rate Limiting با:

MFA،

Passkey،

Bot Detection،

IP Reputation،

Device Intelligence،

CAPTCHA،

Credential Breach Detection،

Monitoring

ترکیب شود.

OWASP نیز توصیه می‌کند مقابله با Credential Stuffing براساس چند سیگنال و چند کنترل باشد و تنها به یک Threshold قابل پیش‌بینی تکیه نکند.

Progressive Enforcement

به جای:

Threshold reached
↓
Block 24 hours

می‌توان Response تدریجی داشت:

Normal traffic
↓
Soft rate limit
↓
Small delay
↓
CAPTCHA
↓
MFA challenge
↓
Temporary block
↓
Security review

این روش False Positive کمتری ایجاد می‌کند.

Backoff چیست؟

Client قانونی بعد از دریافت 429 نباید فوراً دوباره Request ارسال کند.

می‌تواند از Backoff استفاده کند.

مثلاً:

1 second
2 seconds
4 seconds
8 seconds

این مدل Exponential Backoff نام دارد.

برای جلوگیری از هم‌زمان شدن هزاران Client، معمولاً Jitter نیز اضافه می‌شود.

مثلاً به جای دقیقاً 8 ثانیه:

7.3 seconds
8.6 seconds
7.8 seconds

Client Libraryهای API بهتر است رفتار Backoff مشخصی داشته باشند.

Rate Limit و Cache

Cache می‌تواند Load را قبل از رسیدن به Backend کاهش دهد.

اگر یک Resource عمومی میلیون‌ها بار درخواست شود اما CDN پاسخ Cacheشده بدهد، Backend Load بسیار کمتر می‌شود.

Rate Limiting و Caching مکمل‌اند.

Cache:

درخواست تکراری را ارزان می‌کند.

Rate Limit:

رفتار Client را کنترل می‌کند.

Rate Limit و Circuit Breaker

فرض کنید سرویس اصلی به یک API خارجی وابسته است.

اگر API خارجی کند شود، Requestهای داخلی ممکن است صف ایجاد کنند.

Circuit Breaker می‌تواند موقتاً Call را متوقف کند.

Rate Limit ورودی را کنترل می‌کند.

Circuit Breaker وابستگی خراب را مدیریت می‌کند.

Timeout نیز مدت انتظار را محدود می‌کند.

در معماری Resilient معمولاً هر سه وجود دارند.

Logging در Rate Limiting

هر Rate Limit Event نباید بدون فکر Log شود.

در حمله بزرگ ممکن است میلیون‌ها Event ایجاد شود و Logging خودش باعث DoS شود.

باید Structured Logging و Aggregation داشت.

مثلاً:

endpoint
limit_policy
partition_type
source_ip
account_id_hash
timestamp
decision

از ثبت Secretها خودداری شود.

Metricهای مهم

برای Monitor کردن Rate Limit:

Allowed requests
Throttled requests
Rejected requests
429 rate
Unique sources
Top endpoints
Top IPs
Top accounts
Burst frequency
Latency
Queue size

باید Baseline Traffic عادی مشخص باشد.

افزایش ناگهانی:

429

می‌تواند Attack باشد.

اما ممکن است Configuration خیلی سخت‌گیرانه نیز باشد.

Alerting

مثلاً Alert:

Login 429 rate > 20%
for 5 minutes

یا:

Password reset requests
increased 10x

یا:

One ASN targeting 5000 accounts

Alert باید Actionable باشد.

اگر هر Spike کوچک Alert تولید کند، SOC دچار Alert Fatigue می‌شود.

False Positive

Rate Limiting اگر بد تنظیم شود می‌تواند کاربران واقعی را Block کند.

سناریوهای رایج:

دفتر شرکتی با یک IP مشترک،

دانشگاه،

Carrier-Grade NAT موبایل،

VPN عمومی،

Crawler قانونی،

Partner API،

Batch Job،

Mobile App هنگام Reconnect.

به همین دلیل Threshold باید با Data واقعی Tune شود.

Rate Limiting در حالت Dry Run

بعضی سیستم‌ها امکان Dry Run دارند.

یعنی Rate Limiter تصمیم می‌گیرد چه Requestهایی باید Block شوند اما واقعاً آن‌ها را Reject نمی‌کند.

فقط Metric ثبت می‌شود.

این روش برای Deploy اولیه بسیار مفید است.

می‌توان چند روز Traffic را مشاهده و سپس Policy را فعال کرد.

NGINX نیز برای Rate Limit قابلیت Dry Run ارائه می‌کند.

سیاست سخت‌گیرانه بیش از حد نیز خطرناک است

Rate Limit خیلی پایین ممکن است نوعی Self-DoS ایجاد کند.

مثلاً:

1 request/minute per IP

روی API عمومی تقریباً Application را غیرقابل استفاده می‌کند.

Security همیشه تعادل میان:

Abuse Resistance

و

Legitimate Usage

است.

Rate Limiting در WordPress

WordPress Core به‌تنهایی برای تمام مسیرها یک سیستم جامع Rate Limiting عمومی ارائه نمی‌کند.

در یک سایت WordPress باید مسیرهای حساس جداگانه بررسی شوند.

مانند:

/wp-login.php
/wp-json/
/xmlrpc.php
WooCommerce login
Password reset
Registration
Contact forms
Comment forms
Custom AJAX

کنترل Rate Limiting می‌تواند در:

CDN،

WAF،

NGINX،

Apache Module،

Security Plugin،

یا Custom Application Layer

اعمال شود.

Rate Limit روی wp-login.php

WordPress Login هدف رایج Botهاست.

بهتر است Limit فقط تعداد کل Requestهای سایت نباشد.

Login Policy جدا داشته باشد.

برای Administratorها MFA نیز فعال شود.

Rate Limiting Password Guessing را کند می‌کند اما Password ضعیف را امن نمی‌کند.

XML-RPC

اگر سایت واقعاً به XML-RPC نیاز ندارد، کاهش سطح حمله ممکن است شامل غیرفعال کردن قابلیت‌های غیرضروری باشد.

اگر نیاز وجود دارد، Rate Limit و Authentication Monitoring باید متناسب با Workflow تنظیم شوند.

صرف تغییر URL Login راهکار امنیتی کافی نیست.

WordPress REST API

REST API ممکن است Endpoint عمومی و خصوصی داشته باشد.

همه Routeها هزینه یکسان ندارند.

Endpoint عمومی Read-Only می‌تواند Limit متفاوتی با:

User Registration،

Search،

AI Plugin،

Form Submission

داشته باشد.

Pluginها نیز ممکن است Routeهای خود را بسازند.

بنابراین Inventory API اهمیت دارد.

WooCommerce

WooCommerce علاوه بر Login می‌تواند Endpointهای حساس دیگری داشته باشد:

Coupon،

Cart،

Checkout،

Search،

Password Reset،

Review،

Account،

Store API.

Rate Limiting نباید باعث خراب شدن Checkout واقعی شود.

به همین دلیل Business Flow باید تست شود.

Contact Form

Contact Form بدون Rate Limiting ممکن است برای:

Spam،

Email Flooding،

Mail Reputation Abuse

استفاده شود.

علاوه بر Rate Limit می‌توان:

Honeypot،

CAPTCHA مبتنی بر Risk،

CSRF Protection

و Server-Side Validation

داشت.

Rate Limiting در سطح Database

معمولاً Database خودش آخرین جایی است که باید Abuse را ببیند.

بهتر است Request قبل از Query پرهزینه Reject شود.

مثلاً:

CDN
↓
API
↓
Rate Limit
↓
Database

نه:

Database expensive query
↓
Then rate limit

Rate Limiter باید تا حد امکان قبل از Resource پرهزینه قرار گیرد.

Rate Limiting و Authentication Timing

در Login باید مراقب باشید Rate Limiting باعث User Enumeration نشود.

مثلاً اگر Account واقعی بعد از سه Attempt 429 بگیرد اما Account جعلی همیشه 401، Attacker می‌تواند وجود Account را تشخیص دهد.

Policy و Error Response باید با Threat Model Authentication هماهنگ شوند.

Rate Limiting و Privacy

Rate Limit State ممکن است شامل:

IP،

Account ID،

Device Identifier

باشد.

این داده‌ها ممکن است Privacy Implication داشته باشند.

Retention باید محدود باشد.

لازم نیست تمام IPها سال‌ها برای Rate Limiting ذخیره شوند.

TTL مناسب روی Counterها اهمیت دارد.

Rate Limit Bypass از طریق Header

اگر Rate Limit بر اساس IP باشد اما Application بدون کنترل به:

X-Forwarded-For
X-Real-IP
Forwarded

اعتماد کند، Client ممکن است Key خود را تغییر دهد.

فقط Reverse Proxyهای Trusted باید اجازه تعیین IP واقعی را داشته باشند.

این یکی از خطاهای رایج Deployment است.

Rate Limit Bypass از طریق Case یا Path

اگر:

/login
/Login
/login/
/login?x=1

در Routing به یک Endpoint برسند اما Rate Limiter آن‌ها را Routeهای جداگانه در نظر بگیرد، Policy ممکن است شکسته شود.

Normalization مسیر اهمیت دارد.

Rate Limit Bypass از طریق چند Endpoint

فرض کنید:

/api/v1/login
/api/v2/login
/mobile/login

همه Authentication انجام می‌دهند.

اگر فقط V2 محدود باشد، مهاجم V1 را انتخاب می‌کند.

تمام Authentication Surface باید Inventory شود.

Rate Limit Bypass در Microserviceها

API Gateway ممکن است Limit داشته باشد اما یک Internal Service مستقیماً از اینترنت قابل دسترسی باشد.

در این صورت Gateway Bypass می‌شود.

Network Policy باید تضمین کند Client خارجی فقط از مسیر کنترل‌شده وارد Backend شود.

چگونه Limit مناسب انتخاب کنیم؟

هیچ عدد جهانی مثل:

60 req/min

برای همه سایت‌ها وجود ندارد.

اول Traffic واقعی را اندازه‌گیری کنید.

مثلاً P50، P95 و P99 تعداد Request User عادی.

سپس Burst طبیعی را بررسی کنید.

بعد Endpoint Cost را ارزیابی کنید.

برای Login رفتار متفاوت است.

برای Search متفاوت.

برای Public API متفاوت.

Policy باید براساس:

Business Need،

Capacity،

Abuse Risk،

User Behaviour،

Cost per Request

تنظیم شود.

Load Testing

قبل از Production بهتر است Rate Limit زیر Load قانونی تست شود.

مثلاً مشخص شود:

آیا 100 User هم‌زمان Login می‌کنند؟

آیا Mobile App بعد از Offline شدن Burst ایجاد می‌کند؟

آیا Retry Logic Client باعث Request Storm می‌شود؟

آیا Reverse Proxy Counter درست Share می‌شود؟

Load Test به جلوگیری از Self-DoS کمک می‌کند.

Security Testing Rate Limiting

در تست دفاعی باید بررسی شود:

1. آیا Endpoint حساس Rate Limit دارد؟
2. Key چیست؟
3. آیا IP قابل Spoof است؟
4. آیا per-account Limit وجود دارد؟
5. آیا Distributed Attempt دیده می‌شود؟
6. آیا Token Bucket یا Window Boundary مشکل دارد؟
7. آیا API Version دیگر Limit را دور می‌زند؟
8. آیا Rate Limit Server-Side است؟
9. آیا 429 درست برگردانده می‌شود؟
10. آیا Response اطلاعات حساس درباره Policy افشا می‌کند؟
11. آیا Counter بین Nodeها Shared است؟
12. آیا Reset Counter قابل Abuse است؟
13. آیا Anonymous و Authenticated Policy متفاوت‌اند؟
14. آیا Business Operation Limit وجود دارد؟
15. آیا Failure سیستم Rate Limiter رفتار امنی دارد؟

هدف Security Test اثبات کنترل است، نه ایجاد اختلال در Production.

اشتباهات رایج در Rate Limiting

فقط Rate Limit براساس IP

حملات Distributed می‌توانند آن را دور بزنند و NAT می‌تواند False Positive ایجاد کند.

یک Limit برای کل سایت

Endpointها Cost و Risk متفاوت دارند.

Limit فقط در Frontend

JavaScript نمی‌تواند Security Boundary باشد.

Attacker مستقیماً API را Call می‌کند.

Rate Limiting بعد از عملیات پرهزینه

اگر Query یا SMS قبل از Check انجام شود، Limit ارزش خود را از دست می‌دهد.

Fixed Window بدون توجه به Boundary

Burst در مرز Window ممکن است نرخ واقعی را بسیار بیشتر کند.

نمایش جزئیات بیش از حد

اطلاعات دقیق Counter می‌تواند Automation را آسان کند.

Block دائمی IP

IP ممکن است Shared یا Dynamic باشد.

Mitigation موقت و Adaptive معمولاً بهتر است.

نادیده گرفتن IPv6

Rate Limiting IPv6 فقط براساس یک Address دقیق می‌تواند با Rotation Address دور زده شود.

Policy باید معماری IPv6 را در نظر بگیرد.

Trust کردن X-Forwarded-For از همه

مهاجم می‌تواند Identity Rate Limit را تغییر دهد.

Counter محلی در معماری Distributed

Limit روی هر Server مستقل چند برابر می‌شود.

نبود TTL

Counterهای قدیمی می‌توانند Storage را پر کنند.

عدم Monitoring

اگر هیچ‌کس 429ها را نمی‌بیند، Rate Limiter تنها Block می‌کند اما Attack Intelligence تولید نمی‌کند.

Limit بسیار پایین

User واقعی Block می‌شود.

Limit بسیار بالا

عملاً هیچ امنیتی ایجاد نمی‌کند.

چک‌لیست امنیتی Rate Limiting

1. تمام Endpointهای حساس را Inventory کنید.
2. Login Policy جدا داشته باشد.
3. Password Reset را محدود کنید.
4. OTP Send و OTP Verify جدا محدود شوند.
5. Registration محدود شود.
6. Contact Form محدود شود.
7. Search Endpoint براساس Cost محدود شود.
8. APIهای پرهزینه Limit سخت‌گیرانه‌تر داشته باشند.
9. Rate Limit فقط per-IP نباشد.
10. per-account Counter داشته باشید.
11. برای API از API Key یا Client ID استفاده کنید.
12. در صورت نیاز Device Signal اضافه کنید.
13. Multiple Independent Buckets استفاده کنید.
14. IP+Username را تنها Bucket Login قرار ندهید.
15. رفتار NAT را در نظر بگیرید.
16. VPN و Proxy Networkها را در Threat Model قرار دهید.
17. IPv6 را فراموش نکنید.
18. الگوریتم متناسب انتخاب کنید.
19. Burst قانونی را پشتیبانی کنید.
20. Fixed Window Boundary را بررسی کنید.
21. برای API حساس Token Bucket یا Sliding Window را ارزیابی کنید.
22. Counter Update را Atomic کنید.
23. State را در معماری Distributed Share کنید.
24. TTL برای Counterها داشته باشید.
25. Failure Mode Rate Limiter را تعریف کنید.
26. قبل از Operation پرهزینه Limit را بررسی کنید.
27. File Size را جدا محدود کنید.
28. Concurrent Request Limit داشته باشید.
29. Pagination Limit داشته باشید.
30. Query Complexity را محدود کنید.
31. GraphQL Batch Limit داشته باشید.
32. WebSocket Message Limit داشته باشید.
33. WebSocket Connection Limit داشته باشید.
34. External Service Spending Limit داشته باشید.
35. SMS Cost را کنترل کنید.
36. Email Flood را کنترل کنید.
37. AI Usage Quota تعریف کنید.
38. Endpoint Cost متفاوت را در Policy لحاظ کنید.
39. HTTP 429 را درست استفاده کنید.
40. در API عمومی Retry Behaviour را مستند کنید.
41. Policy Authentication اطلاعات بیش از حد افشا نکند.
42. Trusted Proxy را درست پیکربندی کنید.
43. Client IP را از Header غیرقابل‌اعتماد نگیرید.
44. Pathها را Normalize کنید.
45. APIهای Legacy را بررسی کنید.
46. Mobile Endpointها را فراموش نکنید.
47. Internal Serviceها را مستقیماً Public نکنید.
48. Dry Run قبل از Enforcement انجام دهید.
49. Metricهای 429 را مانیتور کنید.
50. Thresholdها را با Traffic واقعی Tune کنید.
51. Alert برای تغییر غیرعادی Traffic بسازید.
52. False Positiveها را اندازه‌گیری کنید.
53. Mitigation موقت را به Block دائمی ترجیح دهید.
54. MFA را در Authentication کنار Rate Limiting استفاده کنید.
55. Bot Detection را اضافه کنید.
56. CAPTCHA را Risk-Based استفاده کنید.
57. DDoS Protection را جای Rate Limiting ندانید.
58. CDN و Cache را برای کاهش Load استفاده کنید.
59. Security Test دوره‌ای انجام دهید.
60. Policy را با تغییر Traffic و Business مرتب بازبینی کنید.

یک نمونه معماری امن برای Login

یک Login Flow مقاوم‌تر می‌تواند چنین باشد:

Request
↓
CDN / Bot Detection
↓
IP / ASN Rate Limit
↓
Account Rate Limit
↓
Credential Validation
↓
Risk Analysis
↓
MFA در صورت نیاز
↓
Session Creation
↓
Monitoring

اگر رفتار مشکوک باشد:

Normal
↓
Delay
↓
CAPTCHA
↓
MFA
↓
Temporary Mitigation

به این ترتیب هیچ عامل واحدی مسئول تمام امنیت نیست.

یک نمونه معماری امن برای API

Client
↓
API Gateway
↓
API Key Validation
↓
Per-IP Rate Limit
↓
Per-client Rate Limit
↓
Endpoint-specific Cost Limit
↓
Application
↓
Resource Quota
↓
Database / Third-party Service

این معماری هم Burst را کنترل می‌کند و هم سوءاستفاده طولانی‌مدت را.

Rate Limiting در سطح Business Logic

یکی از مهم‌ترین نکات این است که بعضی Limitها اصلاً HTTP Rate Limit نیستند.

مثلاً:

حداکثر 3 برداشت مالی در دقیقه

یا:

حداکثر 5 Coupon Attempt در ساعت

یا:

حداکثر 10 دعوت‌نامه در روز

این‌ها Business Rate Limit هستند.

حتی اگر Client 1000 HTTP Request مجاز در دقیقه داشته باشد، نباید بتواند 1000 تراکنش مالی انجام دهد.

Security باید Business Action را نیز محدود کند.

Rate Limit و Idempotency

برخی Clientها پس از Timeout Request را Retry می‌کنند.

اگر عملیات مالی Idempotent نباشد، Retry ممکن است عملیات را دوبار انجام دهد.

Rate Limiting این مشکل را حل نمی‌کند.

برای Operation حساس باید Idempotency Key نیز وجود داشته باشد.

مثلاً:

POST /payment
Idempotency-Key: ...

در این صورت Retry Client باعث Transaction تکراری نمی‌شود.

این نمونه خوبی است که نشان می‌دهد Rate Limiting تنها بخشی از Secure API Design است.

آیا می‌توان Rate Limiting را دور زد؟

هیچ کنترل امنیتی مطلق نیست.

Attacker می‌تواند:

IP توزیع کند،

Request را آهسته‌تر کند،

Device تغییر دهد،

Account متعدد استفاده کند.

هدف Rate Limiting «غیرممکن کردن همه حملات» نیست.

هدف:

کاهش سرعت،

افزایش هزینه مهاجم،

حفظ Resource،

تشخیص رفتار غیرعادی

و ایجاد فرصت برای سایر لایه‌های دفاعی

است.

همین موضوع دلیل اهمیت Defense in Depth است.

سؤالات متداول درباره Rate Limiting

Rate Limiting چیست؟

Rate Limiting مکانیزمی است که تعداد یا سرعت درخواست‌های یک Client را در یک بازه زمانی محدود می‌کند. Client می‌تواند براساس IP، User، Account، API Key، Device یا ترکیبی از چند Signal شناسایی شود.

چرا Rate Limiting برای امنیت سایت لازم است؟

زیرا بدون محدودیت، Bot یا مهاجم می‌تواند Login، API، Reset Password، OTP، Search و سایر قابلیت‌ها را با حجم بسیار بالا فراخوانی کند و باعث Brute Force، Abuse، Spam، افزایش هزینه یا Denial of Service شود.

آیا Rate Limiting جلوی DDoS را می‌گیرد؟

به تنهایی خیر. Rate Limiting بیشتر برای Application-Layer Abuse مفید است. DDoS حجیم ممکن است به CDN، Anycast Network و سرویس تخصصی DDoS Protection نیاز داشته باشد.

بهترین Rate Limit چقدر است؟

عدد ثابت جهانی وجود ندارد. Limit باید براساس رفتار واقعی کاربران، Endpoint، هزینه پردازش، ظرفیت زیرساخت و Risk کسب‌وکار تعیین شود.

آیا 100 درخواست در دقیقه عدد مناسبی است؟

ممکن است برای یک API مناسب و برای API دیگر بسیار زیاد یا بسیار کم باشد. این مقدار فقط پس از تحلیل Traffic و Cost قابل انتخاب است.

آیا Rate Limit فقط باید براساس IP باشد؟

خیر. IP به تنهایی قابل تغییر و Shared است. در Endpointهای حساس بهتر است IP با Account، User، Device، API Key یا Signalهای دیگر ترکیب شود.

HTTP 429 چیست؟

429 Too Many Requests Status Code استاندارد برای شرایطی است که Client تعداد بیش از حد Request در یک بازه زمانی ارسال کرده است. RFC 6585 این Status را برای Rate Limiting تعریف می‌کند.

Retry-After چیست؟

Retry-After Header می‌تواند به Client بگوید چه مدت قبل از Request بعدی صبر کند. RFC 9110 مقدار آن را به‌صورت Date یا تعداد ثانیه تعریف می‌کند.

Token Bucket چیست؟

Token Bucket الگوریتمی است که برای هر Request یک Token مصرف می‌کند و Tokenها با نرخ مشخص دوباره تولید می‌شوند. این روش امکان Burst کوتاه و کنترل نرخ بلندمدت را فراهم می‌کند.

Sliding Window چیست؟

در Sliding Window تعداد Requestها در بازه زمانی منتهی به لحظه فعلی بررسی می‌شود. این مدل مشکل Burst مرزی Fixed Window را کاهش می‌دهد.

Leaky Bucket چیست؟

Leaky Bucket Requestها را با نرخ کنترل‌شده از Queue عبور می‌دهد و در صورت پر شدن ظرفیت، Request اضافی را Reject می‌کند. NGINX Rate Limiting از مدل Leaky Bucket استفاده می‌کند.

آیا Login به Rate Limiting نیاز دارد؟

بله. Login یکی از مهم‌ترین Endpointهایی است که باید در برابر Brute Force، Credential Stuffing و Password Spraying محدود شود.

آیا Rate Limit برای Login فقط per-IP کافی است؟

خیر. بهتر است حداقل per-account و per-IP به‌صورت مستقل بررسی شوند تا هم Targeted Attack توزیع‌شده و هم Credential Stuffing از یک Source شناسایی شوند.

Forgot Password هم باید Rate Limit داشته باشد؟

بله. در غیر این صورت مهاجم می‌تواند Email Flooding و Abuse ایجاد کند.

OTP به چه Rate Limiting نیاز دارد؟

هم ارسال OTP و هم Verify کردن Code باید Limit جداگانه داشته باشند. Rate Limit Verify برای جلوگیری از Brute Force Code بسیار مهم است.

آیا Rate Limiting باید در Frontend انجام شود؟

Frontend می‌تواند UX را بهتر کند، اما Security Control باید Server-Side باشد. مهاجم JavaScript سایت را دور می‌زند و مستقیماً API را فراخوانی می‌کند.

Rate Limiting در WordPress چگونه انجام می‌شود؟

می‌توان در CDN، WAF، Reverse Proxy، Security Plugin یا Application Layer Rate Limit اعمال کرد. مسیرهایی مانند Login، REST API، Reset Password، Comment و Formها باید جداگانه بررسی شوند.

آیا WAF برای Rate Limiting کافی است؟

WAF لایه بسیار مفیدی است اما Business Context کامل Application را همیشه نمی‌داند. بهتر است Application نیز Limitهای User و Operation را enforce کند.

Rate Limiting چه ارتباطی با API Security دارد؟

APIها می‌توانند CPU، RAM، Bandwidth، Storage و سرویس‌های پولی Third-Party مصرف کنند. OWASP محدودسازی تعامل Client با API را یکی از کنترل‌های اصلی جلوگیری از Unrestricted Resource Consumption معرفی می‌کند.

جمع‌بندی

Rate Limiting یکی از بنیادی‌ترین کنترل‌های امنیتی برای سایت‌ها، APIها و Applicationهای مدرن است.

هدف Rate Limiting فقط جلوگیری از «درخواست زیاد» نیست.

این مکانیزم مشخص می‌کند هر Client با چه سرعت، چه تعداد و با چه هزینه‌ای اجازه استفاده از Resourceهای سیستم را دارد.

بدون Rate Limiting، قابلیت‌های کاملاً قانونی سایت می‌توانند علیه خود سیستم استفاده شوند.

Login می‌تواند به Brute Force تبدیل شود.

Reset Password می‌تواند Email Flood ایجاد کند.

OTP می‌تواند هدف Guessing یا SMS Abuse قرار گیرد.

Registration می‌تواند توسط Botها پر شود.

Search می‌تواند Database را تحت فشار بگذارد.

و یک API پرهزینه می‌تواند هزینه Cloud یا سرویس خارجی را افزایش دهد.

اما یک Rate Limit ساده براساس IP پاسخ کامل نیست.

IP ممکن است Shared، Dynamic یا قابل تغییر باشد.

حملات مدرن می‌توانند درخواست‌های خود را میان هزاران Proxy توزیع کنند.

به همین دلیل طراحی حرفه‌ای باید چند Dimension را در نظر بگیرد:

IP
Account
User
Device
API Key
ASN
Endpoint
Operation
Cost
Time

برای Login حداقل per-account و per-source باید جداگانه بررسی شوند.

برای APIهای تجاری، API Key و Quota اهمیت دارند.

برای عملیات پرهزینه، Weighted یا Cost-Based Limiting می‌تواند دقیق‌تر باشد.

انتخاب الگوریتم نیز اهمیت دارد.

Fixed Window ساده است اما در مرز Window Burst ایجاد می‌کند.

Sliding Window رفتار دقیق‌تری ارائه می‌دهد.

Token Bucket Burst قانونی را پشتیبانی می‌کند و نرخ بلندمدت را کنترل می‌کند.

Leaky Bucket Traffic را Smooth می‌کند و در ابزارهایی مانند NGINX استفاده می‌شود.

هنگام عبور Client از Limit، HTTP 429 Status مناسبی است و در APIهای عمومی می‌توان از Retry-After برای راهنمایی Client استفاده کرد.

در عین حال، Policy امنیتی نباید اطلاعات بیش از حدی درباره Thresholdهای Login در اختیار Attacker قرار دهد.

Rate Limiting باید قبل از عملیات پرهزینه اعمال شود.

اگر ابتدا Password Hashing، Query سنگین، ارسال SMS یا AI Generation انجام شود و بعد Rate Limit بررسی شود، کنترل عملاً دیر اجرا شده است.

در معماری Distributed نیز Counterها باید هماهنگ باشند.

اگر هر Application Node Limit مستقلی داشته باشد، Client ممکن است سهمیه خود را با توزیع Request بین Nodeها چند برابر کند.

Monitoring نیز بخش جدایی‌ناپذیر Rate Limiting است.

افزایش 429، تعداد بالای Accountهای هدف، Burst غیرعادی یا Requestهای زیاد از ASN مشخص می‌تواند نشانه حمله باشد.

در نهایت Rate Limiting یک دیوار مستقل نیست.

بهترین نتیجه زمانی حاصل می‌شود که در کنار:

MFA،

Passkey،

Bot Detection،

CAPTCHA مبتنی بر Risk،

WAF،

DDoS Protection،

Timeout،

Resource Limit،

Monitoring

و Business Rules

قرار گیرد.

Rate Limiting یعنی سیستم از قبل تعیین کند چه میزان استفاده طبیعی و قابل قبول است، پیش از آنکه مهاجم با مصرف نامحدود منابع این تصمیم را به جای سیستم بگیرد.