How to secure production APIs against the most common attacks — authentication, authorization, rate limiting, input validation, and the OWASP API risks every team should design against.
APIs are where your data lives, which makes them the favourite target of attackers. And because APIs are consumed by machines, a weakness gets exploited at scale and automatically. Security can't be bolted on later — it has to be designed in. Here are the practices we build into every API, aligned with the OWASP API Security risks.
The core controls
Authentication done right Verify who is calling. Use short-lived tokens (JWT/OAuth) or securely managed API keys, never credentials in URLs. Rotate secrets and store them properly (a secrets manager, not in code).
Authorization on every request This is the most commonly botched control. Authentication proves who you are; authorization proves you're allowed to touch *this* resource. Check ownership on every object access — "broken object-level authorization" (a user fetching another user's record by changing an ID) is the single most common serious API flaw.
Rate limiting and throttling Limit requests per client to stop abuse, brute-force, and denial-of-service. This applies to public and authenticated endpoints alike — exactly the kind of control we recently added to this site's own contact API.
Validate and sanitize all input Never trust client input. Validate types, ranges, and formats, and use parameterized queries to prevent SQL injection. Schema validation (for example with Zod) at the boundary stops a whole class of attacks.
Additional protections
- HTTPS everywhere — no exceptions, for every endpoint.
- Correct CORS policy — allow only the origins that should call your API, not a wildcard.
- Don't leak data in responses or errors — return only the fields the client needs; avoid verbose stack traces in production.
- Log and monitor access — you can't respond to an attack you can't see. Alert on anomalies.
- Keep dependencies patched — most breaches exploit a known, unpatched vulnerability.
- Get periodic security reviews — a professional [audit or penetration test](/services/) catches what internal teams miss.
Frequently asked questions
What's the most common API vulnerability? Broken object-level authorization — failing to check that the authenticated user actually owns the resource they're requesting. Always verify ownership per object.
Are API keys enough for security? API keys identify a caller but aren't a complete solution. Combine them with proper authorization, rate limiting, HTTPS, and input validation.
How often should APIs be security-tested? Build security in continuously, and run a formal review at least annually or after major changes — sooner if you handle sensitive or payment data.
Handling sensitive data through your APIs? Talk to us about a security review, or about building your APIs secure by design.