feat(rate-limit): return 429 with Retry-After headers and safe-error …#313
Merged
mikewheeleer merged 1 commit intoJun 2, 2026
Merged
Conversation
…contract - Update src/middleware/rateLimiter.ts to return RFC 6585 compliant 429 responses - All 429 responses now include Retry-After header as required by RFC 6585 - Standardize error responses to follow safe-error contract (CWE-209 compliance) - Error messages are sanitized via sanitizeErrorMessage() to prevent info disclosure - Consistent safe message: 'Too many requests — please try again later' - X-RateLimit-* headers continue to reflect rate limit state - X-RateLimit-Blocked header indicates when client is hard-blocked - Improve documentation in docs/request-limits-implementation.md with: - RFC 6585 compliance details - 429 response format specification - Client backoff guidance and retry examples - Updated test coverage requirements Security notes: - No internal limiter state leaks to clients - Error messages remain consistent regardless of block reason - requestId enables client-server log correlation - Aligned with safe-error policy to prevent CWE-209 vulnerabilities
|
@Abolax123 Great news! 🎉 Based on an automated assessment of this PR, the linked Wave issue(s) no longer count against your application limits. You can now already apply to more issues while waiting for a review of this PR. Keep up the great work! 🚀 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Closes #259
Overview
This PR implements RFC 6585 compliant 429 Too Many Requests responses with proper HTTP headers and alignment with the safe-error contract policy. When request limits are exceeded, the API now returns standards-compliant responses with
Retry-Afterheaders instead of generic errors that may leak internal state.Problem Statement
Solution
Changes Made
1. src/middleware/rateLimiter.ts
sanitizeErrorMessagefromsrc/errors/safeErrors.tsretryAfterfield from response body (redundant with Retry-After header)Retry-Afterheader is always set when sending 429 response2. docs/request-limits-implementation.md
RFC 6585 Compliance
✅ HTTP 429 status for all rate limit responses
✅ Retry-After header (seconds format per RFC 6585)
✅ X-RateLimit-Limit header (max requests)
✅ X-RateLimit-Remaining header (requests left)
✅ X-RateLimit-Reset header (seconds until reset)
✅ X-RateLimit-Blocked header (true when hard-blocked)
✅ Safe error response body per error contract
✅ requestId for log correlation
Security
Response Format
Headers