Rate limits are not security controls

Problem

Rate limiting is currently not a substitute for backend authentication and authorization.

Observed behavior:

• The limiter keys off request-supplied X-User-Id or X-Forwarded-For.
• Those values can be spoofed or unstable depending on proxy configuration.

Risk

Rate limits may reduce abuse volume but cannot prove caller identity or protect user-specific resources. If protected endpoints rely on rate limits instead of authentication/ownership checks, authorization bypasses remain possible.

Expected behavior

Rate limiting should remain a defense-in-depth control, while backend auth and ownership checks enforce access decisions.

Acceptance criteria

• Protected endpoints do not rely on request-supplied X-User-Id as an identity source.
• Rate-limit keys use trusted request metadata or verified authenticated identity.
• Proxy/header trust boundaries are documented.
• Tests cover spoofed X-User-Id/forwarded-header behavior where practical.

Start by locating the rate limiter and the protected endpoints that use request-supplied X-User-Id or forwarded headers. Trace how identity and proxy metadata are trusted, then review the existing tests before adding coverage for spoofed headers. Done means access decisions use verified identity or ownership checks, rate limiting remains defense in depth, and trust boundaries are documented.