Yes, but log them carefully. Record the first hit and the periodic summary for each actor and route, with the limit that fired. Keep a counter for total volume. Logging every rejected request can flood your log store and turn the control into a cost and availability problem.
What a rate limit event tells you
A rate limit trips for three reasons: a broken client, a heavy but legitimate user, or abuse. The log entry is how you tell them apart later. It also proves the control works, which matters when a customer or auditor asks.
The OWASP Logging Cheat Sheet lists excessive use as an optional event class, and its Logging Vocabulary has example names such as excess_rate_limit_exceeded and excess_sessions_exceeded. The OWASP REST Security Cheat Sheet says to return 429 Too Many Requests when requests are coming in too quickly.
Fields to capture
- Actor: user, API key ID or source address.
- Route template, not the raw URL.
- Which limit fired, such as per minute per key.
- The configured limit and the observed count.
- Window start and end.
- Action taken: rejected, delayed, or temporarily blocked.
- Request ID of the first rejected request.
Avoiding a flood
The OWASP Logging Cheat Sheet asks teams to make sure logging cannot be used to exhaust resources. A rate limiter that writes one log line per rejected request lets an attacker fill your log pipeline by sending more requests. See log pipeline flooding and disk fill.
| Technique | How it works | Trade off |
|---|---|---|
| First hit event | Log the first rejection per actor and window | Loses count of the rest |
| Periodic summary | Every minute, log a count per actor and route | Slight delay |
| Metric counter | Increment a counter on every rejection | No per request detail |
| Escalation event | Log again when an actor crosses a higher tier | Needs state |
A good default is first hit plus a summary plus a counter. The counter feeds dashboards and alerts cheaply. The events give you the detail for investigation.
What to alert on
- A sustained climb in total rejections, from the counter.
- One actor hitting limits across many routes.
- Many different actors hitting the same route, which may mean a campaign or a release bug.
- A limit that never fires on a login route, which may mean it is not working.
Rate limits are also a credential attack control, so connect them to your credential stuffing detection. The OWASP credential stuffing guidance recommends graduated responses and temporary blocks over a single fixed limit.
Steps
- Emit a structured event from the limiter, with the fields above.
- Add deduplication by actor, route and window.
- Add a counter metric with a low cardinality label set, route and limit name only.
- Test by exceeding a limit in staging and checking one event and one counter increment appear.
- Review limits every quarter against real traffic.
Quick check
Should the 429 response include details?
Keep it simple. A retry hint is helpful, but do not reveal internal limit logic to an attacker.
Why not log every rejected request?
Under attack that creates the flood you are trying to survive. Summaries and counters give you the picture at lower cost.
Safeguard's SBOM and dependency scanning helps you track the gateway and framework versions that enforce limits. Try a free scan at gold.safeguard.sh/scan.
Sources
- OWASP Logging Cheat Sheet
- OWASP Logging Vocabulary Cheat Sheet
- OWASP REST Security Cheat Sheet
- OWASP Credential Stuffing Prevention Cheat Sheet
Last reviewed: 19 October 2026.
