API penetration testing
API penetration testing that proves each flaw with a working exploit
Many serious API bugs are authorization bugs: the API answers a request it should have refused. From outside, the response looks normal, and the bug is that it came back at all. Rheono's agents test your API with the test accounts you provide, inside a scope you sign, and report a finding only when a working exploit backs it.
The OWASP API Security Top 10 (2023), and what the agents do with each
Each entry of the 2023 list, and how a Rheono pentest treats it. Within limits means the agents test it where that is possible without load, data changes or third-party systems. OWASP API Security Top 10 (2023)
An endpoint takes an object ID from the request and returns the object without checking that the caller may see it.
The agents ask for other users' objects with your test accounts and keep the request and response as evidence. The worked example below is this class.
Flaws in login, tokens or sessions let an attacker act as another user.
Login, session and token handling, tested with the accounts you provide.
A caller can read or change fields of an object that their role should not reach.
Part of the authorization tests: responses are checked for fields the caller's role should not see. Setting fields changes data, so that part runs only if you approve it in writing.
No limits on requests or payloads, so a caller can exhaust the service or run up the bill for a paid dependency.
Denial of service is out of scope unless you approve it in writing, so by default the agents do not flood your API to prove a missing limit.
A normal user can call admin or other privileged functions.
Privileged functions are called with a normal role's session, using the roles you put in scope.
A flow such as checkout or sign-up can be abused in a way that hurts the business.
Payment and checkout flows are probed for logic flaws and race conditions, without abusing them at volume.
The API fetches a URL the caller supplies, and can be pointed at internal or unintended hosts.
Parameters that take a URL are tested, and a finding needs proof that the server made the request.
Settings across the stack leave a door open.
Exposed services and settings on the authorized hosts, reported when the agents can show what an attacker gains from them.
Old API versions and forgotten endpoints stay online without anyone watching them.
Recon maps the domains, subdomains and endpoints of the authorized hosts, so an old version that recon finds on one of them gets tested too. Hosts outside the authorization are left alone.
The API trusts data from a third-party API more than it trusts user input.
Only where it shows from outside. The third-party systems themselves are out of scope unless you approve them in writing.
Worked example: BOLA on /v1/orders/{id}
This is the finding from the sample report, an IDOR, which OWASP files under API1:2023. The company and data are made up (acme.example); the shape is the real deliverable.
sample report · fictitious data
- Asset
- https://api.acme.example/v1/orders
- Severity
- High, CVSS 3.1 score 8.1
- CWE
- CWE-639
What the agents did
- 1Logged in as the provided test account (testuser1) and called GET /v1/orders/1001: its own order, HTTP 200. That is the baseline.
- 2Called GET /v1/orders/1002: another customer's order, also HTTP 200, with items, address and payment reference.
- 3Ran evidence/poc.sh, a read-only script over IDs 1001 to 1010: every one returned 200.
- 4Kept the evidence: the raw request and response for order 1002, and an enumeration log that records 41 foreign orders read.
Why it worked
Order IDs are sequential, and the ownership check lived only in the frontend. The API accepted any logged-in session for any order ID.
The fix
Resolve the owner on the server from the authenticated session, reject the request when the order belongs to someone else, and add a regression test.
evidence/poc.sh (read-only)
BASE="https://api.acme.example/v1"
COOKIE="session=***" # testuser1
for id in $(seq 1001 1010); do
code=$(curl -s -o /dev/null -w '%{http_code}' -H "Cookie: $COOKIE" "$BASE/orders/$id")
echo "order $id -> HTTP $code"
doneFound 24.08.2026. Fixed 25.08.2026 in release 2026.08.2. Retested 26.08.2026 and closed.
Read the full sample reportWhat a pentest tests in an API
- Object and function level authorization: one user's session against another user's objects, and a normal role against admin functions.
- Authentication: login, sessions and tokens, with the test accounts you provide.
- Business logic: race conditions, payment and checkout flows.
- Injection, such as SQL injection and SSRF, where the API passes input on.
- Recon of the authorized hosts: domains, subdomains and endpoints. The authorization names the API paths and roles in scope, and you can attach an OpenAPI spec.
- With repo access, as a flat add-on agreed in writing: each release diff read for data-flow and auth issues, with file:line in the finding.
What it does not test
- Denial of service or load testing, unless you approve it in writing. By default nothing in the pentest floods or degrades your API.
- Destructive or data-changing attacks, unless you approve them in writing.
- Hosts you did not authorize, and third-party services your API calls, unless the authorization names them.
- Internal networks, mobile binaries, social engineering and physical access.
How each finding is checked
The agent that finds a flaw proves it once. A separate validator, which never saw that work, gets only the claim, the endpoint and the scope, and tries to reproduce it. For bug classes with a deterministic check, IDOR among them, a scripted replay runs the exploit again and captures the request and response. Only then does the finding reach the report, which the signatory reviews and signs.
The verification barWhat it costs
An API is priced as part of a surface: one web app and its API. Starter is one full pentest a month for €99. Growth is €499 a month and runs a pentest after each release you approve, with a quieter watch between releases. More pentests do not raise the bill.
FAQ
- What is BOLA?
- Broken Object Level Authorization, first in the OWASP API Security Top 10 (2023). An endpoint takes an object ID from the request and returns or changes the object without checking that the caller may access it. IDOR, insecure direct object reference, is the common name for the same class of bug.
- Do you need our OpenAPI spec?
- It helps, and you can attach it to the authorization. Recon also maps the endpoints on the authorized hosts, so an endpoint missing from the spec gets tested too if recon finds it.
- Will testing change or delete our data?
- Not by default. The pentest runs at non-destructive intensity: denial of service and data-changing attacks are excluded unless you approve them in writing. Authenticated tests use the test accounts you provide, and the sample report's PoC only reads.
- What does the free check do on an API?
- It is a short read-only pass over the public site: at most about 300 requests at about one per second, with no logins and no exploit payloads. It shows what is exposed. Authorization testing with your accounts happens in the pentest.
- How is an API pentest priced?
- Flat, per surface. A web app and its API are one surface: €99 a month on Starter, which is one full pentest a month, and €499 a month on Growth for continuous coverage.
See what your API exposes
The free check is read-only and takes about 20 minutes. If you want the full pentest, the plans are on the pricing page.
Comparing options? Rheono vs the alternatives