[TT-6075] Create option to populate the X-ratelimit headers from rate limits rather than quotas #7730
probelabs / Visor: security
failed
Feb 19, 2026 in 1m 41s
🚨 Check Failed
security check failed because fail_if condition was met.
Details
📊 Summary
- Total Issues: 3
- Error Issues: 2
🔍 Failure Condition Results
Failed Conditions
- global_fail_if: output.issues && output.issues.some(i => i.severity === 'critical' || i.severity === 'error')
- Severity: ❌ error
Issues by Category
Logic (2)
- ❌ gateway/mw_organisation_activity.go:241 - The
http.ResponseWriteris passed to a new goroutine inProcessRequestOffThread. Accessing the response writer, including its headers, from a different goroutine than the one handling the HTTP request is not safe and can lead to race conditions. The main handler may finish and write the response before the goroutine can set the rate limit headers, or it could cause a panic due to concurrent map writes on the header map. This is particularly problematic with the newHeaderSenderpattern which modifies headers directly during the rate-limiting check. - ❌ system:0 - Global failure condition met: output.issues && output.issues.some(i => i.severity === 'critical' || i.severity === 'error')
Security (1)
- ℹ️ gateway/session_manager.go:614 - The new feature controlled by
enable_context_variablesadds rate-limit and quota details (limit, remaining, reset) to the request context. This data becomes accessible to any subsequent middleware, including custom plugins (e.g., JSVM, gRPC). If a malicious or poorly written plugin is deployed for an API, it could log this information for all requests, potentially exposing usage patterns or service tier information of different API consumers.
Powered by Visor from Probelabs
💡 TIP: You can chat with Visor using /visor ask <your question>
Annotations
Check failure on line 247 in gateway/mw_organisation_activity.go
probelabs / Visor: security
logic Issue
The `http.ResponseWriter` is passed to a new goroutine in `ProcessRequestOffThread`. Accessing the response writer, including its headers, from a different goroutine than the one handling the HTTP request is not safe and can lead to race conditions. The main handler may finish and write the response before the goroutine can set the rate limit headers, or it could cause a panic due to concurrent map writes on the header map. This is particularly problematic with the new `HeaderSender` pattern which modifies headers directly during the rate-limiting check.
Raw output
Do not pass the `http.ResponseWriter` to the goroutine. The off-thread processing should update a shared state that is safe for concurrent access (like the session object), and a later middleware running in the main request goroutine should be responsible for writing headers based on that state. Given the new architecture, consider disabling the `ExperimentalProcessOrgOffThread` feature when `ratelimit_headers_source` is set to `rate_limits`, as its asynchronous nature is incompatible with synchronously setting response headers from the rate-limiting result.
Check notice on line 623 in gateway/session_manager.go
probelabs / Visor: security
security Issue
The new feature controlled by `enable_context_variables` adds rate-limit and quota details (limit, remaining, reset) to the request context. This data becomes accessible to any subsequent middleware, including custom plugins (e.g., JSVM, gRPC). If a malicious or poorly written plugin is deployed for an API, it could log this information for all requests, potentially exposing usage patterns or service tier information of different API consumers.
Raw output
The feature is safely disabled by default. Ensure that the documentation for `enable_context_variables` clearly warns administrators about this potential information disclosure risk, advising them to enable it only when trusted middleware needs this context and to be cautious about the custom code deployed on the gateway.
Loading