There's no rate limit on the API endpoints. Bots are sending millions of requests and slowing down the server. How many requests/sec should be allowed?
How do you set a rate limit? Do you return info in the headers? How do we warn the mobile app developer?
We have API keys, but everyone uses the same key. Should I set a per-person rate limit?
API Rate Limiting: DDoS prevention + abuse protection. Limits: 1) Global (server-wide): 10000 req/min, 2) Per-user/API key: 100 req/min, 3) Per-endpoint: GET /users 1000/min, POST /users 100/min. Types: 1) Fixed window (per-minute counter reset), 2) Sliding window (rolling clock, more accurate), 3) Token bucket (burst allowance). Implementation: 1) HTTP headers (X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset), 2) Response codes (429 Too Many Requests), 3) Retry-After header (send expected retry time), 4) Rate limit database (Redis optimal, query counts per key). Per-user tracking: API key/token (unique identifier), user ID (if authenticated), IP address (anonymous). Exceed handling: 1) Immediate rejection (429 response), 2) Queue (delayed response), 3) Throttle (slower response). Best practice: graduated limits (free tier: 100/min, paid tier: 1000/min), IP-based fallback (if no auth), burst allowance (Token bucket: 100 normal, 500 burst). Mobile app handling: backoff strategy (exponential: 1s → 2s → 4s), error handling (show message 'rate limited', retry later), caching (minimize API calls).
Doki · Penetration test · 2024
just set a rate limit start with 100 req/min per user. set up redis track request count per key. send 429 response when limit is exceeded. document the headers for the mobile dev — x-ratelimit-remaining...
Edit: asked below, I wrote the answer in the second message.
Rate limiting implementation: 1) Token bucket algorithm (pseudocode: bucket_tokens = min(max_tokens, bucket_tokens + rate*elapsed_time), on request: if bucket_tokens >= 1 → decrement, else 429), 2) Redis key structure (user_id:rate_limit → increment, 60s expire), 3) HTTP headers (response.setHeader('X-RateLimit-Limit', 100), 'X-RateLimit-Remaining', tokens_left, 'X-RateLimit-Reset', reset_time), 4) Endpoint-based limits (middleware config: route → limit mapping). Deployment: API gateway (AWS API Gateway, Kong) handles rate limiting before app logic or app-level (middleware: express-rate-limit, Flask-Limiter). Monitoring: Alert when limit approaches (80%), block repeat offenders (IP blacklist), graduated penalties (increasing delays).
set a rate limit 100 req/min per user. keep a token counter in Rdis and if limit is exceeded send 429 + Retry-After header. recommend 'exponential backoff' to the mobile dev — retry after bot bot. if there's a shared API key, give out individual keys...
Rate limiting strategy: 1) Tiered levels (free: 100/min pro: 1000/min), 2) Endpoint sensitivity (read: high limit, write: low limit) 3) Burst allowance (bucket size > rate — users can spike briefly) 4) User classification (authenticated: higher, anonymous/IP: lower). Monitoring metrics: 429 response rate (track abuse patterns), API usage trend (capacity planning), concurrent users (load estimation). Client-side resilience: exponential backoff (1s, 2s, 4s 8s delays), jitter (randomize to prevent thundering herd), request queuing (batch, off-peak hours).
correct in theory, but it doesn't work that way in practice and hoenstly hasty decisions become decisions you have to fix six months later.
this is my opinion, I'm not claiming it's absolute truth.
I have no experience with api security rate limit, so I'm asking. Taking measures without an inventory leaves doors you haven't seen open.
Hasty decisions become decisions you have to fix six months later. If you post the result here, it will help others too.
My perspective changed after experiencing that. Taking notes for two weeks yields better results than a six-month estimate.
Hope this helps.
Just a heads-up. The answer varies greatly by industry; there is no one-size-fits-all rule.
If you post the result here, it will help others too.
I feel the same way. An untested backup is not a backup.
Start with a small trial; don't commit to everything at once. Good luck with that.
I have a question. If you get three different answers on a topic, the question was asked wrong.
That's all, sorry if I went on too long.
Doki · Corporate website · 2024
I think differently. Just because everyone does it doesn't mean it's right.
When we decide without measuring, we always end up in the same place. Proven by experience.
I'm writing this so you don't make the same mistake. If permission and scope aren't in writing, don't start that test.
Proven by experience.
I'd like to add this, as it's often overlooked on the forum: your time to detect a problem directly determines its cost. Speeding up detection is often cheaper than investing in prevention.
We need to take it step by step. The biggest time-waster for us was not knowing who had the final say.
Hope this helps.