Object-level authorization (BOLA)
Can one user read or change another user's resources by changing an ID in a request? This is the most frequent and most serious control, and we verify it on every endpoint that receives an identifier.
API security · OWASP API Security Top 10 · From €490
REST API penetration test based on the OWASP API Security Top 10
APIs expose data and functions directly, often with no interface to filter what is shown. The most frequent risks concern object-level authorization (BOLA), authentication and token handling, excessive data exposure and business logic. We verify them one by one, with reproducible proof.
Why APIs need a specific test
A web application has an interface that guides the user. An API does not: anyone can send requests, change their parameters and read the responses. If the server does not check properly who can do what, the flaw is often invisible from a browser and easy to exploit with a script.
The OWASP API Security Top 10 is separate from the web application list, because the risks are different. At the top is object-level authorization: in practice, a legitimate user who changes an identifier and reads another user's data.
The checks we run on APIs
Four families of checks, with several test roles to measure the control between users properly.
Authentication and tokens
Login handling, token issuance and expiry, revocation at logout, protection of keys, and whether expired or tampered tokens are accepted.
Data exposure and limits
Do responses return more fields than needed? Are there request limits on sensitive endpoints such as login or password recovery, and can pagination be used to extract large volumes of data?
Business logic
Flows that can be bypassed: prices or quantities the client can change, order states that can be skipped, operations that run out of order or more than once.
How we work on an API, step by step
Four phases, with the API owner informed at every step and no action outside the agreed perimeter.
1. Endpoint mapping
We identify endpoints, methods, parameters, formats and authentication schemes, starting from the documentation when available and from observed traffic in the test environment.
2. Verification of existing controls
We observe how the system responds to requests without credentials, with expired credentials, with different roles and with unexpected input. These are the basis for the tests that follow.
3. API-specific attacks
We run targeted tests on authorization, tokens, data exposure and business logic, with proof of impact and no destructive actions.
4. Report and re-verification
The report reaches the API owner with priorities, reproducible proof and correction guidance. The free re-verification within 30 days closes the cycle.
What we need to work well
None of these items is mandatory, but each one shortens the work and improves coverage.
API documentation
An OpenAPI or Swagger specification, even a partial one. It lets us cover more endpoints in less time and not miss the less obvious ones.
Test accounts with different roles
At least two users with different privileges, and an administrative profile if the API has one. Without them the control between users cannot be verified.
An agreed environment
We prefer a test environment equivalent to production, with dummy data. Testing in production requires windows and written authorization.
A technical contact
Someone who knows the API and can answer questions about expected behaviour, exceptions and business flows.
What API tests usually find
These are not exceptional cases. They are the problems that recur most often in the APIs of real applications.
- A detail endpoint that returns another user's data when the identifier is changed.
- A token that remains valid after logout or after a password change.
- Responses that include internal fields, such as roles, admin flags or system identifiers, not shown by the interface.
- A password recovery endpoint with no attempt limits, exposed to account enumeration.
- A checkout that accepts a price or quantity sent by the client without recalculating it on the server.
What the test does not do
To be clear about the boundaries: the test checks how the API behaves in the agreed environment. It does not replace a code review, and it does not guarantee that a new API is secure after a change. That is why the test should be repeated when the API changes.
How much an API test costs
The Single perimeter plan costs €490 one-off, VAT excluded, for one external domain or API with its subdomains. Large APIs, multiple environments or particularly complex business-logic testing are quoted on request. The full price list is on the home page.
Frequently asked questions on API penetration testing
Is API testing different from website testing?
Yes. APIs have less interface and more objects and roles. The main risk is often BOLA, which does not require bypassing authentication: a legitimate user changing an identifier is enough.
Do we need the API documentation?
It is not mandatory. With OpenAPI or Swagger we cover more endpoints in less time and are less likely to miss any.
Can APIs be tested in production?
Only with written authorization and agreed windows. We usually prefer a test environment equivalent to production.
Can the test modify real data?
In the test environment, yes, to demonstrate impact, and always with dummy data. We run no destructive actions and delete no resources, and every test change is documented in the report.
How much does it cost?
The single perimeter costs €490 one-off, VAT excluded. Large APIs or multiple environments are quoted on request.
Do you have exposed APIs and need to verify their authorization?
Send us the documentation or the list of endpoints: we reply in writing with the proposed perimeter.
Request the API test