Rate Limiting and Abuse Review
By Riles · Published · Updated
Finds where an API can be abused and sets the rate limits, quotas, backoff and responses that stop scraping, credential stuffing and runaway clients.
Prompt template
## Rate Limiting and Abuse Review Review this API for abuse and design its limits. - API description: [textarea: Main endpoints and what each does] - Who calls it: [multi: Browser users, Mobile apps, Partner servers, Public developers, Internal services] - Authentication: [dropdown: None, API key, User session, OAuth] - Costly operations: [textarea: Endpoints that are slow or expensive or send messages] - Current protections: [textarea: Limits or captchas or WAF rules in place] - Infrastructure: [text: Cloud Run behind a CDN or similar] List the endpoints and rank them by how much damage a hostile or buggy caller could do, using three lenses: cost (compute, third-party fees, email or SMS), data (scraping, enumeration of ids, account takeover) and availability (one client starving the rest). For each risky endpoint choose a limit by caller identity, not just IP, with a number, a window and an algorithm (token bucket or sliding window), and say what to do for unauthenticated traffic. Give stricter limits to login, password reset, signup and anything that sends a message. Specify the response: HTTP 429 with a Retry-After header and a clear body. Recommend client backoff with jitter. Add quotas for daily usage, request size limits, pagination caps, and idempotency keys for payments. Note what to log and alert on, and where limits sit: edge, gateway or application.