API security: who may call, what they may touch, how much

API security overlaps with web application security but is not the same: there is no page to hide a button on, so every check has to be on the server.

A web page hides what a user cannot do. An API answers whatever is asked, in a format that is easy to automate. Identifiers in the path can be changed one by one; fields the interface never shows can be sent anyway; a call that is cheap for one user becomes expensive a million times over.

This is why the OWASP API list is dominated by authorisation and resource consumption rather than injection. It is also why API abuse often uses an endpoint exactly as designed.

• Broken object level authorization. Changing an identifier returns someone else's record; see BOLA.
• Broken authentication. Weak tokens, missing expiry, credentials that can be tried without limit.
• Broken property and function level authorization. Fields or admin functions reachable by ordinary users.
• Unrestricted resource consumption. No limits on rate, size or cost per call, which turns into outages and bills.
• Unrestricted access to sensitive business flows. Purchases, sign-ups or bookings automated at a scale the business never intended.
• Improper inventory management. Old versions and forgotten endpoints still answering.

Names follow the OWASP API Security Top 10 2023.

1. Check object ownership on every call. Never trust an identifier because the client sent it.
2. Authenticate every endpoint. Short-lived tokens, verified signatures, keys that can be rotated.
3. Return only the fields the caller may see. And accept only the fields they may change.
4. Limit rate, size and cost. Per key, per user and per endpoint; see limits by IP, user or key.
5. Keep an inventory. Know every version and endpoint that answers, and retire the old ones.
6. Validate input and log decisions. The OWASP REST Security Cheat Sheet covers the details.

• Every endpoint requires authentication, or is listed as public on purpose.
• Every object access checks ownership, including updates and deletes.
• Every list has a page size limit, and every upload a size limit.
• Every key can be revoked without redeploying.
• Errors do not reveal internals, such as stack traces or query fragments.
• Old versions have an end date that is published and enforced.

An API gateway sits in front of services and handles routing, authentication and quotas per key. A web application firewall inspects the content of requests for attack shapes and limits rates. Both work on requests, so both are blind to whether user A should be allowed to read object 42.

That decision lives in the code. The gateway and the filter reduce volume and noise around it; web attacks covers the injection side that a filter does see.