API Security
API security protects your APIs from bots, DDoS, credential abuse and data theft — through authentication, authorization, rate limiting and traffic inspection.
Comprehensive API Protection
Secure your APIs with advanced bot protection
What is API Security?
API security is protecting programmatic interfaces from abuse, which is a different problem from protecting a website. An API has no user interface to put a challenge in, no session cookie to rely on, and clients that are legitimately automated. The usual browser defences do not transfer.
APIs are also where the valuable data is, addressed precisely and returned in a convenient format. A scraper that has to parse your HTML is working; a scraper on your JSON endpoint is being helped.
What actually goes wrong
The OWASP API Security Top 10 is the reference list, and the useful observation about it is that most of it is authorisation logic only your own code can fix:
| Risk | Nature of the fix |
|---|---|
| Broken object-level authorisation | Check on every request that this caller may see this object. Code, not infrastructure. |
| Broken authentication | Correct token validation, expiry and revocation |
| Excessive data exposure | Return the fields the client needs, not the whole record and a filter in the UI |
| Unrestricted resource consumption | A traffic layer: quotas, rate limiting, cost per call |
| Unrestricted access to sensitive business flows | A traffic layer: is this caller entitled to do this at this rate |
| Improper inventory management | Know which versions are deployed and retire the old ones |
Only the two bold rows are addressable from outside the application. The rest need changes where the authorisation decision is made, and no gateway, firewall or bot product fixes them.
Authentication is not authorisation, and neither is anti-abuse
These three get conflated and they answer different questions:
- Authentication: who is calling
- Authorisation: may they do this to this object
- Anti-abuse: should they be allowed to do it this many times, and is there a person behind it where there should be
An API key answers the first. It does nothing about the third, because keys get extracted from mobile apps and front-end bundles and then used at volume by someone other than your customer.
Defending the flows rather than the endpoints
The practical approach is to find the calls that cost you money and defend those specifically:
- The ones that create accounts, send messages, reserve stock or move funds
- Quotas per credential, with the credential being something harder to rotate than an IP address
- Verification of a human at the point where the flow starts, not on every call — which is what agentic clients make necessary, since a legitimate agent acting for a real customer will fail every classic bot test
- Logging the business event, not just the HTTP status, so abuse is visible as a pattern
Prosopo's role here is narrow and clear: we can tell you whether a person is behind a session before it reaches your business logic. The authorisation checks in that table remain yours, and anyone selling an API product that claims otherwise is overstating what a traffic layer can see.