Rate-Limit Absence

Fires on auth-required endpoints whose handler file and the project’s entry points (app.js, server.js, main.py, Program.cs, application.yml, …) show no evidence of a rate-limiting library or middleware. Findings are deduplicated to one per handler file — repeated routes in the same controller produce a single flaw.

Surfaced as LOW severity because static analysis cannot see infrastructure-level limits (gateway, WAF, nginx, reverse-proxy), so the finding is advisory until reviewed against the deployment environment.

Without per-route rate limiting, an authenticated endpoint is a candidate for resource exhaustion (CPU / memory / database connection pool / third-party-API quota), credential-stuffing — even when the endpoint correctly rejects each attempt, throughput becomes the attack — and slow-burn enumeration of any object-id-by-id pattern that BOLA would otherwise be able to defend against.

OWASP API4:2023 — Unrestricted Resource Consumption — is one of the top three categories in public API breach reports. It’s also one of the cheapest to remediate: a single middleware registration covers an entire app.

Add a rate-limit middleware or per-route annotation appropriate to your stack. A few common entry points:

If infrastructure-level limits (nginx limit_req, AWS API Gateway usage plans, Cloudflare rules) already cover the endpoint, document that decision in xygeni.apisecurity.yml so future reviewers know the in-app library is intentionally absent. The detector does not currently introspect infrastructure config, so an exemption file is the right pattern.

This detector does not require specific configuration. The set of recognised rate-limit libraries is built in and covers the mainstream stacks listed above.