The API security definition is the practice of protecting application programming interfaces, the endpoints that expose an application's data and functionality, from unauthorized access, misuse, and abuse across their entire lifecycle. That is the textbook answer, and it is correct, but it hides how much ground the term now covers. An API is a contract that lets one piece of software call another, and modern systems are almost entirely made of these calls: web apps talking to backends, mobile clients talking to servers, microservices talking to each other, and third parties talking to all of them. Securing that surface is a distinct discipline because APIs fail differently than the web pages that preceded them.
The short version of why it is its own field: web application security grew up assuming a browser and a human. APIs assume neither. They are consumed by machines, at scale, and they expose logic directly rather than through a rendered page, which changes both the attacks and the defenses.
Why APIs need their own security model
A traditional web page bundles data and presentation together and hides a lot of logic on the server. An API strips the presentation away and exposes structured data and operations directly. That is precisely what makes them useful and what makes them exposed. An attacker does not need to scrape a rendered page; they can read the JSON contract, enumerate object IDs, and call endpoints in any order they like.
The result is that the dominant API risks are not the injection-and-XSS flaws that define classic web security. They are authorization flaws: the API correctly authenticates who you are but fails to check what you are allowed to touch.
What the definition covers in practice
API security spans several concerns that together make up the working definition:
- Authentication: verifying the identity of the caller, typically via tokens such as OAuth 2.0 access tokens or API keys.
- Authorization: enforcing what an authenticated caller may do and which objects they may access. This is where most real breaches happen.
- Data exposure: ensuring endpoints return only the fields a caller needs, rather than dumping full objects and trusting the client to hide the rest.
- Rate limiting and abuse prevention: protecting against enumeration, credential stuffing, and denial-of-service through excessive calls.
- Transport security: encrypting traffic with TLS so tokens and data cannot be read in transit.
- Inventory: knowing which APIs exist, including the forgotten and undocumented ones, because you cannot protect an endpoint you do not know you run.
That last point deserves weight. "Shadow" and "zombie" APIs, old versions left running after a redesign, are a leading cause of breaches precisely because no one is watching them.
The OWASP API Security Top 10
The authoritative reference for the field is the OWASP API Security Top 10, a list dedicated to API-specific risks rather than general web risks. Its top entries reflect the authorization reality above. Broken Object Level Authorization, usually abbreviated BOLA, sits at the top, and it describes exactly the failure where an API checks that you are logged in but not that the specific record you requested belongs to you.
GET /api/v1/accounts/1043/statements
Authorization: Bearer <valid token for user 5001>
If the server returns account 1043's statements to a user who owns account 5001, that is BOLA. The token is valid; the authorization check is missing. The fix is to verify object ownership on every request, server-side, using the authenticated identity rather than trusting an ID supplied by the client.
Broken authentication and excessive data exposure round out the recurring themes. None of them are exotic. They are the boring, systematic checks that get skipped when an endpoint is written quickly.
How to build API security in
The controls follow the definition:
- Enforce authorization on every object and every function, server-side, derived from the session identity. Never trust a client-supplied ID or role.
- Return minimal data. Design responses around what the caller needs, and filter server-side rather than in the client.
- Validate every input against a schema. An API contract (OpenAPI) doubles as a validation spec, rejecting malformed requests at the edge.
- Rate-limit and monitor. Throttle by identity and watch for enumeration patterns.
- Maintain an inventory. Discover and document every endpoint, and decommission the ones you no longer use.
Third-party API clients and SDKs are dependencies like any other, and a vulnerability in the HTTP or authentication library your service links against undermines all of the above. Cataloguing those through an SCA workflow keeps a known-vulnerable client library from being the weak link, and the Academy covers the secure-design side of building API contracts.
FAQ
What is the definition of API security?
API security is the practice of protecting APIs, the endpoints exposing an application's data and functionality, from unauthorized access, misuse, and abuse across their whole lifecycle. It spans authentication, authorization, data exposure, rate limiting, transport encryption, and endpoint inventory.
How is API security different from web application security?
Web application security assumes a browser and a human viewing rendered pages. APIs are consumed by machines at scale and expose structured data and logic directly, so the dominant risks shift from injection and XSS toward authorization flaws like accessing objects that belong to another user.
What is BOLA in API security?
BOLA, Broken Object Level Authorization, is the top OWASP API risk. It occurs when an API verifies that a caller is authenticated but fails to check that the specific object they requested belongs to them. The fix is to verify object ownership server-side on every request.
Why does API inventory matter for security?
You cannot protect an endpoint you do not know exists. Forgotten "shadow" and outdated "zombie" APIs are a common breach source because no one monitors or patches them. Discovering, documenting, and decommissioning endpoints is a core part of API security.