Summary
The default ClientIpKeyResolver in api-gateway builds rate-limit keys from the leftmost value in the client-controlled X-Forwarded-For header. An attacker can supply changing header values to receive separate buckets, potentially bypassing request-rate limits on routes using the default configuration.
The default ClientIpKeyResolver in api-gateway builds rate-limit keys from the leftmost value in the client-controlled X-Forwarded-For header. An attacker can supply changing header values to receive separate buckets, potentially bypassing request-rate limits on routes using the default configuration.
Affected context
This issue affects api-gateway deployments that use the shipped default ClientIpKeyResolver and apply rate limits based on client IP information. It becomes risky when the gateway accepts X-Forwarded-For values from untrusted clients without first determining whether the request passed through an authorized reverse proxy or validating the trusted proxy chain.
This issue affects api-gateway deployments that use the shipped default ClientIpKeyResolver and apply rate limits based on client IP information. It becomes risky when the gateway accepts X-Forwarded-For values from untrusted clients without first determining whether the request passed through an authorized reverse proxy or validating the trusted proxy chain.
Exploit preconditions
- Attack surface: HTTP routes protected by the gateway's default rate-limiting configuration
- Required access: Ability to send requests to the gateway
- Trigger point: Rate-limit key generation from the
X-Forwarded-Forrequest header - Why exploitation is possible: The resolver treats attacker-controlled header values as independent client identities without restricting them to trusted proxy-provided data
- Attack surface: HTTP routes protected by the gateway's default rate-limiting configuration
- Required access: Ability to send requests to the gateway
- Trigger point: Rate-limit key generation from the
X-Forwarded-Forrequest header - Why exploitation is possible: The resolver treats attacker-controlled header values as independent client identities without restricting them to trusted proxy-provided data
Why this happens
The underlying flaw is the use of an untrusted request attribute as an authorization and resource-accounting identity. The default resolver selects the leftmost X-Forwarded-For value without verifying that it was inserted by a trusted proxy, allowing a client to influence the bucket used for rate-limit enforcement. This behavior primarily maps to CWE-639: Authorization Bypass Through User-Controlled Key, with related concerns involving incorrect authorization and improper privilege management.
The underlying flaw is the use of an untrusted request attribute as an authorization and resource-accounting identity. The default resolver selects the leftmost X-Forwarded-For value without verifying that it was inserted by a trusted proxy, allowing a client to influence the bucket used for rate-limit enforcement. This behavior primarily maps to CWE-639: Authorization Bypass Through User-Controlled Key, with related concerns involving incorrect authorization and improper privilege management.
Potential impact
- An attacker may bypass configured request-rate limits
- Protected routes could receive excessive requests from a single actor
- Backend services may experience resource exhaustion or degraded availability
- Abuse controls, quota policies, and per-client protections could become ineffective
- Downstream systems may be exposed to increased automated traffic
- An attacker may bypass configured request-rate limits
- Protected routes could receive excessive requests from a single actor
- Backend services may experience resource exhaustion or degraded availability
- Abuse controls, quota policies, and per-client protections could become ineffective
- Downstream systems may be exposed to increased automated traffic
General mitigation guidance
Mitigation generally focuses on ensuring that rate-limit identities are derived from trustworthy, stable attributes.
Common defensive patterns include:
- Use the network-observed peer address unless a request is confirmed to have passed through an authorized proxy
- Configure an explicit trusted-proxy allowlist and process forwarded headers only within that trust boundary
- Prefer authenticated principals, API credentials, or other server-validated identities for quota enforcement where appropriate
- Reject, normalize, or ignore client-supplied forwarding headers that are not established by trusted infrastructure
- Apply layered limits, such as global, credential-based, route-based, and backend resource limits
- Run rate-limit storage and enforcement with appropriate isolation and availability protections
Mitigation generally focuses on ensuring that rate-limit identities are derived from trustworthy, stable attributes.
Common defensive patterns include:
- Use the network-observed peer address unless a request is confirmed to have passed through an authorized proxy
- Configure an explicit trusted-proxy allowlist and process forwarded headers only within that trust boundary
- Prefer authenticated principals, API credentials, or other server-validated identities for quota enforcement where appropriate
- Reject, normalize, or ignore client-supplied forwarding headers that are not established by trusted infrastructure
- Apply layered limits, such as global, credential-based, route-based, and backend resource limits
- Run rate-limit storage and enforcement with appropriate isolation and availability protections
How teams detect issues like this
Organizations can identify this class of issue through:
- Static analysis and code review rules that flag rate-limit keys derived directly from request headers
- Review of proxy trust configuration and forwarded-header handling
- Tests that compare rate-limit behavior for requests with varying client-supplied identity headers
- Policy checks requiring authenticated or server-validated identities for quota and abuse controls
- Monitoring for one source generating many apparent client identities or unusually high request volumes
- Automated security review tools that correlate user-controlled inputs with authorization and resource-limiting decisions
Organizations can identify this class of issue through:
- Static analysis and code review rules that flag rate-limit keys derived directly from request headers
- Review of proxy trust configuration and forwarded-header handling
- Tests that compare rate-limit behavior for requests with varying client-supplied identity headers
- Policy checks requiring authenticated or server-validated identities for quota and abuse controls
- Monitoring for one source generating many apparent client identities or unusually high request volumes
- Automated security review tools that correlate user-controlled inputs with authorization and resource-limiting decisions
Sources
| Source | Link |
|---|---|
| github. | github.com/ |
| github. | github.com/ |
| gitlab. | gitlab.eclipse.org/ |
