API security testing: the OWASP API Security Top 10 and the API pentest approach

Where a user once interacted with an application through a web page, traffic now largely runs through APIs: the interfaces that let mobile apps, single-page applications, partners and internal systems exchange data. That shift has changed the way applications are attacked. A modern web application is often little more than a shell around a collection of API endpoints, and that is where most vulnerabilities now sit. Yet when organizations scope a pentest, they still tend to think about testing the visible web interface while the underlying API stays out of scope. That is a missed opportunity, because an attacker rarely targets the buttons you see and almost always targets the traffic beneath them.

Why an API pentest requires a different focus

In a classic web application test, the tester mainly looks at what the application offers through the browser. With an API, that visual context is missing. There is no menu that reveals which functions exist and no screen that indicates which fields a user is allowed to see. An API endpoint accepts a structured request and returns a structured response, and security must be enforced entirely on the server side. That is exactly where things go wrong: developers sometimes rely on the assumption that only their own frontend calls the API, while an attacker does not respect that assumption. He talks directly to the API, manipulates every field, invents endpoints that are not in the documentation, and sends precisely the requests the frontend would never send.

The OWASP API Security Top 10

API security has its own reference framework: the OWASP API Security Top 10. This is a separate list alongside the well-known OWASP Top 10 for web applications, precisely because API-specific risks have their own character. The current edition contains ten categories that we work through systematically during an API pentest.

API1 Broken Object Level Authorization (BOLA). This is by far the most common and most impactful API vulnerability. It comes down to an endpoint returning an object based on an identifier without checking whether the requester is entitled to that specific object. We test this by making a request with account A and then replacing the identifier with that of account B. If that succeeds, a user can retrieve the data of any other user. It is the digital equivalent of a numbered vault where every key fits every lock.

API2 Broken Authentication. This is about how the API establishes identity. We test for weak or missing token validation, tokens that never expire, predictable API keys, and login and recovery processes without protection against brute force and credential stuffing.

API3 Broken Object Property Level Authorization. This category combines returning too much data and accepting too much data. An API that returns a full user object including internal fields, or that blindly accepts every submitted field during an update (mass assignment), allows an attacker to, for example, set their own role to administrator.

API4 Unrestricted Resource Consumption. Without limits on requests, result size or computation time, an attacker can overload the service or drive up costs unnecessarily. We assess rate limiting, pagination and restrictions on heavy operations.

API5 Broken Function Level Authorization. Where BOLA is about objects, this is about functions. Can an ordinary user call an administrative function simply by guessing the right endpoint or HTTP method? Administrative endpoints that are only hidden by the frontend but not protected on the server side are a classic finding.

API6 Unrestricted Access to Sensitive Business Flows. This category looks at automated abuse of legitimate functionality, such as mass buying up of stock or automated account creation. The question is whether there are countermeasures against automated abuse of sensitive business processes.

API7 Server Side Request Forgery. If an API makes requests based on user-supplied URLs, an attacker can force the server to reach internal systems or cloud metadata endpoints. We test whether external input is validated before the server itself opens a connection.

API8 Security Misconfiguration. Incorrect CORS settings, missing security headers, verbose error messages and enabled debug functionality all enlarge the attack surface. These are often quick to remediate.

API9 Improper Inventory Management. Organizations lose track of which API versions run where. A forgotten test environment or an old, unpatched v1 next to the current v2 is a favorite target. We therefore actively try to find undocumented and outdated endpoints.

API10 Unsafe Consumption of APIs. Applications often trust data from external APIs more than input from users. We assess whether responses from third parties are treated with the same suspicion as user input.

Our approach in practice

A good API pentest starts with the documentation. An OpenAPI or Swagger specification, or a Postman collection, speeds up the work considerably, but we do not rely on it blindly. The endpoints that are not in the documentation are exactly the interesting ones. We prefer to work with at least two test accounts with different permissions, so we can thoroughly test authorization between users and between role levels. We then combine automated tooling for broad coverage with manual investigation of the logic behind the endpoints. That manual work is decisive with APIs, because authorization and business logic flaws cannot be found by a scanner. They require an understanding of what the application is supposed to do and what a user should specifically not be able to do.

From finding to remediation

The value of an API pentest lies in what happens afterwards. Our report describes for each finding the impact, the exploitability and concrete remediation advice, with prioritization based on actual risk rather than a CVSS score alone. After remediation we perform a retest as standard, because a finding is only closed once it is demonstrably and fully resolved. Considering a pentest? Then explicitly include the APIs in scope, including the internal and mobile ones. That is often exactly where the real risk sits.