API penetration testing

API penetration testing

We test your API for the flaw that costs most: one user reading or changing another user's data. Every endpoint in scope, tested as each role.

What we test

• Object-level access: can account B read, change or delete account A's record by its ID?
• Function-level access: can a normal user call an admin endpoint or method?
• Mass assignment: can a user set fields such as role or credit?
• Injection: SQL injection and server-side requests through parameters.
• Limits and exposure: rate limits on login, GraphQL fields, and responses that return too much.

What we need

An OpenAPI file, a Postman collection or a GraphQL schema makes the work faster. Add one test account for each role. For a multi-tenant product, add two test tenants with sample data.

What it looks like

For each endpoint we send the same request as different users: the owner, another user, a lower role and nobody. We try other users' identifiers. A write counts only when a second account reads the change back. Control requests show which protections held.

Why API tests find what scanners miss

A scanner can see that an endpoint answers. It cannot know that invoice 8841 belongs to someone else. Authorization depends on your business rules, so we test it with two or more accounts and read the result back. This is why an API test needs accounts for each role, and why we read each change back from a second account.

Where it stops

We test the systems you authorize in writing. We do not test internal networks or physical sites. We do not run social engineering against staff, and we do not run denial-of-service or load tests.

How an engagement runs

1. Scoping call. A short call about what you need, who will read the report and your deadline. We send a written scope and a quote.
2. Authorization. Testing starts only after the owner of each system signs written authorization. Do not send passwords or keys.
3. Testing. We test inside the agreed scope, with test-owned accounts and data.
4. Report. You get evidence, reproduction steps and a fix for each finding.
5. Retest. After you ship fixes, we can verify them. The quote states the retest terms.

Safety limits

• We test only with written authorization from the system owner.
• Destructive proofs use only accounts and records we create for the test, marked as test data.
• Tests of uploads, password guessing, email sending and paid third-party APIs have limits, and the report states what they cost.
• Reproduction scripts are read-only where possible.

What you get

A report in HTML, PDF and Markdown, with proof-of-concept scripts. Each finding has the requests and responses, reproduction steps and a fix. Read the sample report, written for a fictional app.

• Scope, assets and a four-level severity scale: Critical, High, Medium and Low
• An executive summary with priority actions
• One section per finding: description, impact, verified results, reproduction and fix
• Controls that held, so your fix does not break them
• A remediation plan, plus limitations and open questions

Proof from our own research

Each post below has a local fixture with real recorded requests and responses. The code is public in web-security-fixtures on GitHub.

• Authorization testing for APIs
• OWASP API Top 10: tests you can run
• IDOR: a local example with PUT and DELETE
• Mass assignment: a local reproduction
• GraphQL introspection: disabling it leaves the field open

Questions

Which APIs do you test?

REST, GraphQL and other HTTP APIs, inside the scope you authorize.

Do you need the source code?

No. Testing is black-box by default. Share source or documents if you can, and say so on the scoping call.

Is the API test part of a web app test?

It can be. List both in the scope, or see web application penetration testing.

Do you test in production?

We can, with tighter limits. We agree them in the scope. A staging environment is better.

How much does it cost?

We quote the scope in writing after a short call. We publish no prices.

To see how a quote is built, read pricing. For the full method, read application security assessment.