Modern applications rarely work as one piece of software. A mobile app may call dozens of APIs. A web application may use separate services for accounts, payments, search and notifications. A business system may connect to external providers through APIs as well.
That makes API security a central part of application security. An API can expose sensitive data and business operations even when the visible website looks secure.
The OWASP API Security Top 10:2023 is a useful starting point because it focuses specifically on risks that arise at API boundaries. OWASP lists broken object level authorization, broken authentication, object property authorization failures, unrestricted resource consumption, broken function level authorization, sensitive business flows, SSRF, security misconfiguration, inventory problems and unsafe consumption of APIs. OWASP API Security Top 10:2023 provides the full framework.
What is an API?
An Application Programming Interface, or API, is a defined way for software components to communicate. A browser might request /api/orders/123, while a mobile application sends a JSON request to create an order. The exact technology can vary, but the security questions remain similar.
An API usually has to answer several questions for every sensitive request:
- Who is making the request?
- Is the credential or session valid?
- What operation is being requested?
- Which object or resource is involved?
- Is this user allowed to perform that operation on that resource?
- Is the input valid and safe?
- Is the request within acceptable usage limits?
- Should the result contain all of the requested data?
A secure API treats these as separate checks rather than assuming that one successful login makes everything else safe.
Authentication is only the beginning
Authentication establishes the identity of the caller. Common approaches include session cookies, access tokens, OAuth-based flows, mutual TLS and other mechanisms appropriate to the architecture.
The security problem starts when authentication is implemented incorrectly. Weak token handling, poor session management, accepting invalid credentials or accidentally exposing credentials can allow an attacker to act as another user.
But even a perfectly authenticated user should not automatically have access to every resource. That is where authorization becomes critical.
This distinction is especially important in APIs because clients often send resource identifiers directly. A request such as /api/orders/12345 does not prove that the current user owns order 12345.
Broken Object Level Authorization: the classic API mistake
OWASP calls this API1:2023, Broken Object Level Authorization, or BOLA. It occurs when an API lets a caller access an object without checking whether that caller is authorized to access that particular object.
Consider a simplified example:
GET /api/profile/1001
Authorization: Bearer <valid-token>The token may be valid. The endpoint may be legitimate. The security failure occurs if the server returns profile 1001 without checking whether the authenticated user is allowed to read profile 1001.
Changing the identifier to another value is not itself the vulnerability. The vulnerability is the missing authorization decision at the object level.
OWASP recommends checking object-level authorization at every function that uses a client-supplied object identifier. Its BOLA guidance also notes that simply comparing a session user ID with an object ID is not a universal fix because real authorization relationships can be more complex.
Broken Function Level Authorization
Object authorization asks, “Can this user access this particular object?”
Function authorization asks, “Can this user perform this operation at all?”
Suppose a normal user can legitimately call /api/orders. That does not mean the same user should be able to call an administrative endpoint that exports every order or changes system configuration.
OWASP API5:2023, Broken Function Level Authorization, covers this class of failure. A strong design should deny access by default and explicitly grant sensitive functions to the appropriate roles or groups. OWASP’s BFLA guidance explains why hiding an administrative URL is not a substitute for authorization.
Object properties can leak too much
Authorization is not only about entire records. Individual fields can be sensitive.
Imagine an API returning a customer object with:
{
"name": "Example User",
"phone": "+94...",
"address": "...",
"internalRiskScore": 81,
"passwordResetToken": "..."
}The API may correctly decide that the user can access their own record while still returning fields that should never have been exposed.
OWASP API3:2023, Broken Object Property Level Authorization, combines the problems previously described as excessive data exposure and mass assignment. The safer approach is to explicitly select the properties an endpoint needs and explicitly control which properties a client can modify. OWASP’s API3 guidance provides practical prevention advice.
Unrestricted resource consumption
Every API request consumes something: CPU, memory, network bandwidth, database capacity or a paid third-party operation.
An endpoint that accepts unlimited requests or expensive parameters can become a denial-of-service problem or an unexpected cost problem. This is especially relevant when an API triggers emails, SMS messages, image processing, AI inference or other metered services.
Controls should match the operation. Possible measures include:
- rate limits per identity or client;
- request size limits;
- pagination limits;
- maximum query complexity;
- timeouts;
- concurrency limits;
- quotas for expensive operations;
- monitoring for unusual consumption.
Rate limiting is useful, but it should not be treated as the only API security control. A request can be completely within its rate limit and still be unauthorized.
Sensitive business flows need protection
Some API operations are technically valid but economically or operationally sensitive. Examples include creating accounts, redeeming a promotion, sending invitations, booking limited inventory or repeatedly requesting a costly service.
OWASP API6:2023 calls this Unrestricted Access to Sensitive Business Flows. The risk is not always a classic coding bug. The API may perform exactly what it was programmed to do while the business process is abused at scale.
The right control depends on the workflow. Rate limits, quotas, eligibility checks, transaction controls, bot resistance and anomaly detection may all be relevant.
SSRF: when an API fetches something on your behalf
Server-Side Request Forgery can occur when an API accepts a user-controlled URL and the server fetches it without adequately restricting where it may connect.
This matters because the server may have network access that the external user does not. A vulnerable fetch function can potentially be used to reach internal services or unexpected destinations.
OWASP includes SSRF as API7:2023. Protection generally requires careful URL validation, destination restrictions and network-level controls rather than trusting a user-supplied URL simply because it looks like a normal web address.
Security misconfiguration is still an API problem
An API can be coded correctly and still be deployed insecurely.
Examples include:
- debug features exposed in production;
- permissive cross-origin configuration where it is not appropriate;
- unnecessary HTTP methods enabled;
- verbose error responses;
- default credentials or settings;
- exposed management interfaces;
- missing security headers where relevant;
- services reachable from networks that do not need access.
Configuration should be reviewed as part of the application security lifecycle, not treated as a one-time deployment detail.
Know which APIs actually exist
You cannot secure an endpoint you do not know about.
OWASP API9:2023, Improper Inventory Management, highlights the need to maintain an accurate inventory of API hosts, versions and endpoints. Older API versions may remain online after a newer version is released. Test environments or debug endpoints can also become unintentionally reachable.
A practical inventory should answer:
- What API endpoints exist?
- Which version is deployed?
- Who owns each service?
- Which data does it expose?
- Which authentication method does it use?
- Which environments can reach it?
- When will old versions be retired?
API discovery and documentation are therefore security activities, not only developer conveniences.
Third-party APIs are part of your attack surface
Applications often trust external services for payments, maps, messaging, identity, analytics or AI features. That creates another security boundary.
OWASP API10:2023, Unsafe Consumption of APIs, warns against assuming that data received from another API is automatically trustworthy. Your application should validate and handle third-party responses according to their actual trust level.
The same principle applies to API credentials. A key used to access an external provider should have only the permissions and network reach it needs, and should not be exposed to client-side code unless the provider explicitly designs the credential for that use.
A practical API security review
A useful review can follow the request path rather than memorising a list of vulnerabilities.
For each sensitive endpoint, document:
| Question | What to verify |
|---|---|
| Identity | Is the caller authenticated correctly? |
| Object | Is the specific resource authorized? |
| Function | Is the operation allowed for this role? |
| Properties | Are returned and writable fields intentionally limited? |
| Input | Are types, formats and business rules validated? |
| Resources | Are size, rate, cost and complexity bounded? |
| Network | Can the API reach destinations it should not? |
| Inventory | Is the endpoint known, owned and versioned? |
| Dependencies | Are third-party API responses treated as untrusted input? |
| Monitoring | Can unusual requests and authorization failures be detected? |
This approach turns the OWASP categories into questions that can be used during design reviews and testing.
What developers should avoid
Some patterns should immediately trigger a review:
- trusting a client-supplied object ID without checking authorization;
- assuming a valid token means every operation is allowed;
- returning full database objects by default;
- binding arbitrary JSON properties directly to internal objects;
- relying on hidden URLs for admin security;
- allowing unlimited expensive requests;
- leaving old API versions running indefinitely;
- trusting third-party API responses without validation;
- putting private API credentials in browser JavaScript.
The exact risk depends on the application, but each pattern weakens an important boundary.
API security is application security
API security is sometimes treated as a separate specialist topic. In practice, it is closely connected to identity, access control, input validation, business logic, network architecture, secrets management, monitoring and secure development.
The OWASP API Security Top 10:2023 is therefore most useful as a review framework rather than a checklist to tick once. The important habit is to ask what authority each endpoint represents, what data it can expose, what state it can change and what happens when a caller behaves maliciously.
If those questions are answered consistently, API security becomes part of normal software design rather than a final-stage scan.