API Security: What Rate Limiting and a WAF Do and Do Not Solve

Why are APIs a separate security topic?

An API is the application's gateway to data and actions, and it often carries fewer restrictions than the browser UI. An attacker does not fill in a form; they call the endpoint directly and change parameters. That is why the question that works for websites, "is the visitor human?", falls short for APIs.

The OWASP API Security Top 10 lists these risks. In brief:

• BOLA (broken object-level authorization): requesting /orders/124 instead of /orders/123 and reading someone else's data.
• Broken authentication: weak token generation, tokens that never expire, logins open to brute force.
• Unrestricted resource consumption: endpoints with no rate, size or pagination limits.
• Broken function-level authorization: an ordinary user able to call an admin endpoint.
• SSRF, misconfiguration, poor inventory: forgotten old versions that are still live.

What do a WAF and a rate limiter do, and not do?

Set balanced expectations by separating them:

A WAF cannot know that a request is valid but unauthorized. GET /orders/124 is syntactically clean; only the application knows that order does not belong to this user. For how a WAF works in general, see what is a WAF.

How do you design a rate limit?

Pick the key. An IP alone is a blunt key: hundreds of customers behind one office or mobile-carrier NAT look like a single IP. For authenticated APIs a per-token limit is fairer; keep the IP limit as a second layer.

Pick the window. A fixed window allows a burst at the start of each minute. A sliding window gives smoother results.

Report the rejection well. When the limit is hit, return 429 Too Many Requests (RFC 6585) and say how long to wait with the Retry-After header (RFC 9110). Good clients back off by that value; a bare 429 with no hint invites a retry storm.

Weight by cost. A search endpoint and a health check should not share the same limit.

Token scopes and idempotency

Each token should be able to do only what it needs (least privilege). Separate a read-only token from one that creates sites, so a leaked token does limited harm. Make tokens expire and rotate them regularly.

An idempotency key prevents an operation from repeating when the same request is resent after a network error. The client sends a unique value for each logical operation; when the server sees the same value again, it returns the first response. It helps most on payment and resource-creation calls.

Webhooks and mobile apps

Browser-facing verification pages (CAPTCHA, proof-of-work) do not work for clients that do not run JavaScript. A payment system sending webhooks, a mobile app or a server-to-server call cannot solve such a page and gets blocked. The fix is to treat these paths separately: protect webhooks with signature verification on your side, exclude the path from the verification page, and limit it by IP or rate. How the bot side is handled is covered in bot protection.

Common mistakes

• One global limit. Login and password-reset endpoints need a far stricter limit than general read endpoints.
• Limiting only at the edge. Keep per-resource checks inside the application too; if the proxy is bypassed, the application is the last defense.
• Putting the token in the URL. A token in a query string leaks into access logs, browser history and referrers. Use a header.
• Not publishing the limit. If clients do not know it, they retry blindly; document it.

Error responses and inventory

Detailed error messages guide an attacker: stack traces, SQL error text and file paths leak information (CWE-209). Return a generic message and a correlation ID to the client, and keep the detail in the server log.

Inventory is a security job as well. A forgotten /v0 may still be live next to /v1, keeping an old unpatched code path open. List every version, every environment (staging included) and every endpoint, and shut down what is unused. To put staging behind an identity layer, see Zero Trust.

curl -s https://shield.nexren.info/api/v1/whoami \
  -H "Authorization: Bearer YOUR_API_TOKEN"

Checklist

1. Does every endpoint check ownership and role? (BOLA)
2. Are tokens scoped, expiring and rotatable?
3. Are rate limits defined separately for token and IP?
4. Do 429 responses include Retry-After?
5. Are webhook and mobile paths excluded from the verification page, and is there signature verification?
6. Are old API versions in the inventory and shut down?

Sources

• OWASP API Security Project
• RFC 6585: 429 Too Many Requests
• RFC 9110: HTTP Semantics (Retry-After)

Related product pages:Technology