API penetration testing

An endpoint accepts an invoice ID. Can a user in another organization read that invoice? Could someone with read access update or export it? A successful response only tells you the request worked. It does not tell you whether it should have worked.

The OWASP API Security Top 10 lists object-level, property-level, and function-level authorization separately. We choose checks that match your API and its roles.

• Records: whether a user can read or change another user's or tenant's data.
• Roles: whether ordinary users can call privileged actions.
• Fields: whether responses return too much data or updates accept properties the caller should not control.
• Credentials: how tokens, sessions, and recovery flows affect access.

We agree on endpoints and safe limits before testing. The report says which routes we checked, so a result on one workflow is not mistaken for coverage of the whole API.

We check suspected issues with dedicated accounts. A finding includes the affected endpoint or flow, the request and response or other proof, the observed impact, and a fix for your team to evaluate. We retest the same path after a fix is applied.

The sample report shows the format using fictional assets.

• An API description or a list of the endpoints that matter most.
• Test accounts with different roles and, where relevant, separate organizations.
• The environment and limits on data, request rate, or actions.
• Operations that need extra care, such as exports, payments, or invitations.

For testing the product interface too, see web application penetration testing. The preparation guide has more on scope and test access.