API security is the practice of protecting the endpoints your applications expose, where the main risk is not a malformed payload but a valid request asking for someone else’s data.
The short answer
API security covers discovering every endpoint you expose, authenticating and authorising each request, validating what comes in, limiting how often it can be called, and monitoring for abuse. The dominant risk category is broken authorisation: an authenticated user requesting a record that belongs to someone else.
Web application security assumes a browser and a human. APIs have neither. There is no page to render, no session cookie to lean on, and the client is often another machine, which is why attacks look like ordinary traffic.
On this page
You cannot protect what you have not found
Most API incidents involve an endpoint nobody was tracking: a version left running after a migration, an internal service quietly reachable from the internet, a debug route that shipped.
The risks that matter most
| Risk | What it looks like |
|---|---|
| Broken object level authorisation | Changing an ID in the request returns another customer’s record. The top entry in the OWASP API Security Top 10. |
| Broken authentication | Tokens that never expire, weak signing, or endpoints that forgot to require a token at all. |
| Excessive data exposure | The endpoint returns the full object and expects the client to hide the sensitive fields. |
| No rate limiting | An endpoint that can be called endlessly, enabling enumeration and scraping. |
| Shadow and zombie endpoints | Live routes outside the spec, unmonitored and usually unpatched. |
Why scanners miss the worst of it
An authorisation flaw is a perfectly formed request from a valid account. There is no malicious payload to match against a signature, which is why broken object level authorisation is found by testers and by behavioural analysis rather than by a scanner.
Controls that work
Authorise per object
Check ownership on every request, at the data layer. Never trust an ID supplied by the client.
Validate against a schema
Accept only the fields, types and methods the endpoint expects, and reject the rest.
Limit and monitor
Rate limits per client, plus alerting on volume patterns that look like enumeration.
How Osto protects APIs
Osto discovers applications and APIs automatically and applies protection to what it finds, which closes the inventory gap that most API incidents begin with. The engine learns each endpoint’s normal behaviour and generates a positive security policy: expected URLs, parameters, methods and types are allowed, and anything outside that profile is rejected. Cookie security, file upload validation and protection against forced browsing and parameter pollution are enforced at the same layer, and policy recommendations continue as the API changes.
Free security assessment
Find the endpoints nobody documented
Osto discovers your applications and APIs automatically and applies protection to what it finds, including the versions you forgot were live.
Get a free security assessment Book a platform walkthroughAutomatic API discovery · Schema enforcement · One platform, everything
Frequently asked questions
What is API security?
The practice of protecting the endpoints an application exposes: discovering every endpoint, authenticating and authorising each request, validating inputs, rate limiting, and monitoring for abuse.
What is BOLA?
Broken object level authorisation. An authenticated user requests an object belonging to someone else, usually by changing an identifier in the request, and the API returns it because it checked who the user was but not what they were entitled to see.
Is a WAF enough to secure an API?
Not on its own. A WAF blocks malicious payloads and enforces expected structure, which handles a large share of automated attacks. Authorisation logic still has to be correct in the application, because a valid request for the wrong record looks legitimate at the edge.
What are shadow and zombie APIs?
Shadow APIs are endpoints running outside the documented inventory. Zombie APIs are older versions left live after a newer one shipped. Both are usually unmonitored and unpatched, which is why discovery is the first control.