ReferenceIntermediate4-6 min reference
Rate Limiting Testing
Rate limiting protects an API from abuse and overload by capping how many requests a client may make in a window. QA's job is to confirm the limit exists, returns the right signal, and recovers correctly — without launching an actual attack. This sheet is the reference; see Security Headers and the API Negative Testing Matrix for neighbours.
The signals
| Signal | Looks like | Check |
|---|---|---|
| Status | 429 Too Many Requests | Returned once the limit is exceeded |
Retry-After | seconds or HTTP-date | Tells the client when to retry |
X-RateLimit-Limit | e.g. 100 | The cap for the window |
X-RateLimit-Remaining | e.g. 0 | Requests left; decrements each call |
X-RateLimit-Reset | epoch / seconds | When the window resets |
(Header names vary — also RateLimit-* per the draft standard.)
Common strategies
| Strategy | Behaviour |
|---|---|
| Fixed window | N requests per clock window; resets on the boundary |
| Sliding window | N requests over a rolling period |
| Token bucket | Tokens refill at a rate; burst up to bucket size |
| Leaky bucket | Steady drain; smooths bursts |
What QA can safely verify
- The limit triggers at the documented threshold →
429. Retry-Afteris present and honoured (waiting then retrying succeeds).X-RateLimit-Remainingdecrements and resets after the window.- Limits are scoped correctly (per user / IP / API key), not global by accident.
- A
429returns a clean body — no stack trace.
Keep it to documented thresholds; sustained high-volume flooding is load/security-team territory, not a functional check.
Common mistakes
- Confusing
429(rate limit) with503(overload) or403(forbidden). - Testing the limit triggers but never that it resets.
- Ignoring
Retry-After, so a client hammers the API during cooldown. - Assuming one global limit when it's per-key/per-route.
// Related resources