---
name: rate-limiting-and-abuse-review
description: "Finds where an API can be abused and sets the rate limits, quotas, backoff and responses that stop scraping, credential stuffing and runaway clients. Use when an API needs a review for abuse paths such as scraping, credential stuffing or cost attacks, with rate limits and quotas proposed. Do not use for a general security audit or penetration test. Related topics: coding, technical."
---

# Rate Limiting and Abuse Review

Finds where an API can be abused and sets the rate limits, quotas, backoff and responses that stop scraping, credential stuffing and runaway clients.

## When to use

Use this skill when an API needs a review for abuse paths such as scraping, credential stuffing or cost attacks, with rate limits and quotas proposed. Do not use it for a general security audit or penetration test.

## Workflow

1. Ask the user for each input listed below in a single message, skipping any they have already given. Where options are listed, offer them, but accept other answers too.
2. Rank the endpoints by potential damage across cost, data exposure and availability.
3. Assign each risky endpoint a limit keyed by caller identity with a number, a window and an algorithm.
4. Set stricter limits for login, reset, signup and message-sending paths, and a plan for unauthenticated traffic.
5. Specify the 429 response, the Retry-After header and the client backoff with jitter.
6. Add quotas, size caps, pagination caps and idempotency rules, and say where each limit lives and what to alert on.

## Inputs

- **API description** (longer free text)
- **Who calls it** (choose any: Browser users, Mobile apps, Partner servers, Public developers, Internal services)
- **Authentication** (choose one: None, API key, User session, OAuth)
- **Costly operations** (longer free text)
- **Current protections** (longer free text)
- **Infrastructure** (free text, e.g. "Cloud Run behind a CDN or similar")

## Output

A ranked endpoint risk table, a limits table with key, number, window and algorithm, the error response format, client backoff guidance and an alerting list.

## Prompt template

Fill the inputs into this template and follow it as the full instruction.

### Rate Limiting and Abuse Review

Review this API for abuse and design its limits.

- API description: {{API description}}
- Who calls it: {{Who calls it}}
- Authentication: {{Authentication}}
- Costly operations: {{Costly operations}}
- Current protections: {{Current protections}}
- Infrastructure: {{Infrastructure}}

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.

## Pitfalls

- Limiting by IP alone, which blocks shared offices and mobile carriers while a botnet walks through.
- Applying one global limit, so cheap reads and expensive writes share the same ceiling.
- Returning different errors for unknown and wrong passwords, which lets attackers enumerate accounts despite the limit.