APIs have become the connective tissue of modern software. They link microservices, power mobile applications, and enable integrations that organisations depend on daily. They have also become one of the most consistently vulnerable components in enterprise environments and the same classes of vulnerability appear again and again.
The reasons for this are partly structural. APIs often develop quickly, without the same security review cadence applied to traditional web applications. Documentation is incomplete, testing is limited, and security requirements are added late in the development process if they are added at all.
Broken Object Level Authorisation
Broken object level authorisation (BOLA) is the API equivalent of insecure direct object reference. The application exposes an endpoint that accepts an object identifier a user ID, an order number, a document reference and returns the associated data without verifying whether the requesting user has permission to see it.
It sounds straightforward to prevent. In practice, it occurs in nearly every API assessment we conduct. APIs expose hundreds or thousands of endpoints, each of which needs to enforce authorisation correctly. One missed check is enough. Attackers specifically look for numeric or sequential identifiers they can enumerate.
Excessive Data Exposure
APIs frequently return more data than the consuming application actually uses. The mobile app might display three fields from a user profile. The API response contains thirty. That excess data can include information account numbers, personal details, internal flags that the user was never meant to see.
This happens because developers build APIs to serve multiple clients and return a comprehensive response object. The filtering is supposed to happen client-side. When someone calls the endpoint directly, they get everything.
Broken Function Level Authorisation
Administrative functions are often accessible through the same API surface as regular user functions. If the API does not correctly verify that the user has an admin role before processing admin operations, a regular user can call those endpoints directly.
This type of vulnerability is particularly common in versioned APIs. Older versions of endpoints that were intended to be deprecated still exist and still respond often without the security controls that were added to the newer version.
Authentication and Rate Limiting
Token handling is a recurring weakness. JWTs with weak signing algorithms, tokens without expiry, refresh tokens that are valid indefinitely, and secrets stored in client-side code all create usable attack paths.
Rate limiting absent from authentication endpoints means brute force and credential stuffing attacks proceed unchecked. An API that returns a different response for valid versus invalid usernames allows user enumeration. These are basic controls, but they are absent far more often than they should be.
Web application penetration testing of your APIs should cover each of these categories systematically. OWASP maintains a dedicated API Security Top 10 that serves as a practical framework for what a thorough assessment should cover.
What Development Teams Can Do
Security testing belongs in the development lifecycle, not just at the end of it. Threat modelling during design surfaces authorisation requirements before they are implemented incorrectly. Unit tests that validate access control decisions catch regressions before they reach production.
External network penetration testing of your production API surface particularly for APIs that are publicly accessible gives you an honest view of your exposure from an attacker’s perspective. Fixing findings in code is cheaper than responding to an incident.
Developers repeat the same API security mistakes not because they are careless, but because the pitfalls are subtle and the defaults are unsafe. Changing that requires security to be part of the design conversation from the start.
Expert Commentary
William Fieldhouse, Director of Aardwolf Security Ltd
“API security is where we find some of the most impactful vulnerabilities in modern applications. BOLA and excessive data exposure can lead to significant data breaches, and they are both preventable with proper design and testing.”