Design Rate Limits and Key Management for 5 API Tiers

A rate-limiting and key-management policy is where the gateway concepts become concrete: you decide, tier by tier, how fast each caller may go, how much they get per month, and how their keys are scoped, rotated, and revoked. In this exercise you design that policy for MeshAPI, a company exposing one public API across five consumer tiers. First make two design decisions, then write the full policy as YAML — the shape a gateway's configuration actually takes.

The product

MeshAPI exposes a single REST API consumed by five tiers:

Anonymous — unauthenticated callers hitting public, read-only endpoints (docs, status). No key.
Free — signed-up developers evaluating the API. One key, tight limits.
Pro — paying customers running production workloads. Higher limits and quota.
Enterprise — large contracts with negotiated high limits and an SLA.
Internal-service — MeshAPI's own backend services calling the API east-west inside the mesh.

Decision 1: How should the internal-service tier authenticate?

Quick check

The internal-service tier is MeshAPI's own services calling each other inside the zero-trust mesh. How should they authenticate and be rate-limited?

mTLS for authentication (no shared bearer key), with high or no public rate limit but still metered and logged for anomaly detection

The same public API key as Free-tier developers, emailed around the team

No authentication at all, since they are internal

A single shared API key hardcoded in every service

Decision 2: How should a leaked Pro-tier key be handled?

Quick check

A Pro customer reports their API key was committed to a public GitHub repo. What is the correct response?

Revoke the leaked key immediately (logged with timestamp + reason), issue a new scoped key, and review its recent usage for abuse

Ask the customer to delete the GitHub commit; the key is fine once the commit is gone

Rotate it next quarter with the normal schedule

Lower the key’s rate limit so abuse is slower

The free tier discovering you forgot to set a rate limit

Build it: the rate-limit and key-management policy

Now write the full policy. For each of the five tiers define the authentication method, the rate limit (with the algorithm), the monthly quota, the key scopes, and the rotation/revocation policy. Replace every placeholder comment.

Exercise

~15 min

Design MeshAPI's rate-limit and key-management policy

OWASP API4 + SOC 2 CC6.1 Finding

Define rate limits and key lifecycle for five API tiers

ID:

API-GW-6.3.2

Criterion:

Each tier limited and metered; keys scoped, rotated, and revocable; internal uses mTLS

Severity:

Design task

Design authentication, rate limits, quotas, key scopes, and rotation/revocation for MeshAPI's anonymous, free, pro, enterprise, and internal-service tiers.

Auditor Notes

Limits scale by tier and are keyed on the API key / authenticated identity, not IP. Anonymous: no key, low IP-or-global limit, read-only public scope only. Free: one key, tight rate limit + low monthly quota, read scope. Pro: higher limit + quota, read/write scope, scheduled rotation (e.g. 90d), immediate revoke on leak. Enterprise: negotiated high limits + SLA, scoped keys, rotation + revoke. Internal-service: mTLS (no bearer key), very high/no public limit but still metered + logged for anomaly detection. All tiers: rate limit returns 429 with Retry-After; keys stored as hashes; revocation tied to offboarding/leak with logged timestamp + reason.

Write your remediation plan in YAML below. Fill in every field — replace all placeholder comments.

Loading editor…

What to carry forward

A rate-limit and key policy is the gateway turning "secure and meter the API" into concrete, auditable configuration: limits that scale by tier and are keyed on identity (not IP), quotas tied to plans, least-privilege scopes per key, mTLS for internal service traffic, and a key lifecycle where rotation is routine and revocation is immediate and logged. This is the direct mitigation for OWASP API4 and the source of much of your access-control evidence. You now have all three layers of API security — auth, the OWASP failure modes, and the gateway that enforces them. The capstone brings them together on one company's API.