Penetration Testing Hub › Penetration Testing Explained
API Penetration Testing: A Field Guide
Only test APIs you own or have explicit written permission to test. Unauthorised access to a computer system is a criminal offence in Ireland under the Criminal Justice (Offences Relating to Information Systems) Act 2017. Everything below assumes you are testing your own API or one you are formally authorised to assess.
APIs are the plumbing behind modern apps — and they're often less protected than the front end they sit behind, because developers assume nobody's looking directly at them. They are. API testing has become its own discipline, with its own OWASP top-ten list, because the flaws differ from classic web app bugs.
1. How it's done
Discovery and documentation
The tester enumerates endpoints — from documentation (Swagger/OpenAPI), from the app's own traffic captured through a proxy, and by guessing predictable routes. Shadow and deprecated endpoints, still live but forgotten, are a recurring find.
Testing against the OWASP API Top 10
The dominant category is broken object-level authorisation (BOLA) — changing an ID in a request to access another user's object, the API equivalent of the web's number-one flaw. Alongside it: broken authentication, broken function-level authorisation (calling an admin endpoint as a normal user), excessive data exposure (the API returns more than the UI shows), mass assignment, and lack of rate limiting.
What it usually finds
An endpoint that returns any user's record if you change the ID; an API that leaks fields the front end hides; an admin function with no server-side role check; tokens that never expire; and no rate limiting on an expensive or sensitive call.
2. What to look for — the self-check
- Every endpoint checks that the caller owns or may access the specific object requested (test by swapping IDs).
- Function-level authorisation is enforced server-side — admin routes reject non-admin tokens.
- The API returns only the fields the client needs, not the whole database row.
- Authentication tokens expire and can be revoked.
- Rate limiting protects login, search and any expensive endpoint.
- Mass assignment is prevented — clients can't set fields like 'isAdmin' by including them.
- No deprecated or undocumented endpoints are still live.
- Errors don't leak internal detail; input is validated server-side.
3. What to expect if you hire out
Scoping: which API(s), which versions, and access to documentation (an OpenAPI spec makes testing far more thorough). Test accounts at multiple permission levels are essential for authorisation testing.
Duration: often one to two weeks depending on the number of endpoints and roles.
Production risk: mostly low for read testing; write and delete operations are tested carefully, ideally on staging.
The report: findings by severity with example requests, plus remediation and a re-test.
4. When you need a pro
You can test object-level authorisation yourself by swapping IDs as a low-privilege user, and you can review your own endpoints against the checklist. Stop before automated fuzzing of production write/delete endpoints, before anything that could mass-modify real data, and before testing authentication you can't safely reset. Thorough authorisation-matrix testing across many roles and endpoints is where a professional's systematic approach pays off.
Download: API Security Checklist
A printable one-page version of the self-check above. No email required. Open the API Security Checklist
Common questions
How is API penetration testing different from web app testing?
APIs have their own flaw profile — broken object-level authorisation (swapping IDs to reach other users' data) dominates, along with excessive data exposure and missing function-level checks. There's no UI to hide behind, so authorisation must be enforced on every endpoint. OWASP maintains a separate API Top 10 for exactly this reason.
What is BOLA?
Broken Object-Level Authorisation — the most common API vulnerability. It's when an endpoint returns or modifies an object based on an ID in the request without checking the caller is allowed that specific object, so changing the ID exposes someone else's data. You can test for it yourself by swapping IDs while logged in as a low-privilege user.
Can I test my own API for vulnerabilities?
Yes, to a point. You can check object-level authorisation by swapping IDs, review endpoints against the OWASP API Top 10, and confirm tokens expire and admin routes reject normal users. Stop before fuzzing production write operations or anything that could mass-modify real data — that belongs in a controlled professional test.
If you'd rather we tested your API properly — every endpoint, every role — here's how a CyberLabs engagement works.
No prices on this page and no hard sell.
This page is educational and not legal advice. Only test systems you own or are explicitly authorised to test. · ↑ Back to top