How to Scope a REST API Penetration Test (and Pay Less for a Better One)

Most founders find out what a pentest needs from them after they have agreed to buy one. That is backwards, and it costs money.

The price of an API penetration test is decided less by how hard your application is to break than by how much time the tester spends figuring out how it is supposed to work before they can even start. Two clients with near-identical APIs can get quotes that differ by thousands of euros, purely because one of them showed up prepared and the other did not.

This post explains what “prepared” means in plain terms. You do not need to understand any of the technical detail yourself - your developer does. Your job is to read the money logic, then forward the checklist at the bottom to whoever owns your API. Do that, and you get a faster, cheaper, more thorough test.

Why I don’t do “black box” testing (and you shouldn’t pay for it)

There are three ways to run a security test, and the names matter because they decide what you pay for.

Black box means the tester gets nothing - no docs, no accounts, no map. They attack your API the way an anonymous outsider would, discovering everything from scratch. It sounds tough and realistic. In practice, black-box API testing is usually poor value for fixed-budget work. A real attacker has unlimited free time and will happily spend three months poking at your endpoints. You are paying me by the day. If I spend the first three days just finding your endpoints and guessing how they fit together, that is three days I am not spending actually breaking in - and you are paying for the reconnaissance instead of the results.

White box is the opposite extreme: full source code, architecture diagrams, the lot. It has its place for high-assurance work, but for most companies it is overkill. Most external attackers do not start with your full source code, so a test built entirely around having it can chase issues that no real-world adversary could ever reach.

Grey box sits in the middle, and it is what I require for almost every engagement. You give me a working map of your application - what the endpoints are, what the roles are, who is allowed to do what - plus real accounts to log in with. I then attack it like a knowledgeable insider or a logged-in customer who has decided to misbehave. This is both the most realistic threat for most SaaS businesses and the most efficient use of your budget, because I spend my time testing for vulnerabilities instead of reverse-engineering your product.

The two documents I require (non-negotiable)

For any REST API test, two things have to exist and be documented by you. If they do not, I can still do the test - but it moves into discovery work, which takes longer and costs more. That is not a penalty; it is just the meter running while I rebuild information you already have.

1. A role and permission matrix

This is a simple table of every type of user your API has, and what each one is allowed to do - read, write, delete, administer. It can be a spreadsheet. It can be a text file. It does not need to be fancy.

Role      Read         Write        Admin
Guest     public       none         none
Reader    own data     none         none
Editor    own data     own data     none
Admin     all          all          full

Why this one matters more than any other: in my API work, authorization flaws are among the most common severe findings - a user accessing data or actions that should be off-limits to them. In the trade these are called BOLA and BFLA (broken object- and function-level authorization), and OWASP ranks them as API1:2023 and API5:2023. I find them by knowing what each role is supposed to be able to do, then proving it can do things it shouldn’t.

Without your matrix, I have to guess your intended access model first, then test it. Guessing is slow, it is incomplete, and it is exactly the part you are best placed to just tell me. Hand me the matrix and I go straight to breaking it.

2. OpenAPI / Swagger documentation - with a working example file

This is the technical description of your API: every endpoint, what it expects, what it returns. Your developers almost certainly already have it, because modern frameworks generate it automatically.

But a bare spec on its own is not enough. What saves the most time - and the most money - is a fully working, ready-to-run collection your developer can export in a few minutes: a Postman collection or an OpenAPI/Swagger file that already contains real example values, sample variables, and authentication that works. Not placeholders. Not string and 0. Actual values that let me fire a real request and get a real response on the first try.

The difference is stark. With a working collection, I am testing your security within the first hour. Without one, I spend the first day reconstructing how to even call your API correctly - and you pay for that day.

What else helps (your dev will know what these mean)

The two above are mandatory. The following are not required, but each one shaves time off the engagement - which means off the price:

• A short application-logic overview - what each endpoint is for, in business terms. “This one issues refunds.” “This one exports the customer list.” Knowing the stakes tells me where to dig hardest.
• Multi-tenancy boundaries - if you serve multiple customers or organisations from one system, what data must never cross between them? This is the single richest source of serious findings, and the one I most need spelled out.
• One test account per role, pre-created - so I am not blocked waiting for someone to provision logins halfway through the test.
• A dedicated test environment - I always prefer to test against a non-production environment with its own separate database and dummy data, never live customer records. Include simple rules of engagement: rate limits, anything off-limits, and who to call if something looks broken.
• Dummy data I can break - records inside that test database I am free to change or delete without affecting anything that matters.
• How authentication actually works - how a test account logs in and obtains a token, including how to get past MFA on the test accounts.

None of this is your homework. It is a list to forward. Your developer will recognise every item and most of it is a few minutes of export work.

A note on the retest - and why you get paid for what you fix

A pentest finds problems. Then your team fixes them. Then everyone wants to know: did the fixes actually work?

Here is how I handle that, and it is worth understanding before you buy.

Every engagement includes one verification round, within 14 days of the report. After you have remediated, I re-check the specific findings I reported, confirm what is genuinely fixed, and update each item’s status in the report - Open, Fixed, or Not Fixed. You get a clean, updated document you can hand to a customer or auditor. No extra charge for that round.

What is not included is open-ended re-testing. If the first fix did not fully land and needs a second or third pass, if you have changed the application substantially since the test, or if the 14-day window has closed, that becomes a separate, quoted piece of work - usually a quick re-assessment rather than a full new test.

This keeps things honest in both directions. You are not paying twice to confirm I found what I said I found. And the engagement has a defined end, so neither of us is stuck in a remediation loop that drags on for months. The original report is invoiced on delivery, and the verification round follows as part of the same engagement.

If you would rather not think about any of this on a per-project basis, that is exactly what the Retained Security Partner arrangement is for - testing gets scheduled to keep pace with your product, and remediation verification is simply part of the rhythm. I wrote more about why a retainer beats a one-off pentest for a growing company.

The short version

A penetration test is only as good as what you point it at. Bring me a map of your roles and a working description of your API, and you get a sharper test for less money - because I spend every paid hour attacking your security instead of decoding your product.

You do not need to prepare any of it personally. You need to forward one checklist.

Scoping checklist - forward this to whoever owns your API

Ready to scope yours?

1. Grab the checklist above and send it to your developer.

2. Book a free 30-minute scoping call - I will tell you exactly what I will test and what it will cost, before you commit to anything.

3. Join the 2027 waitlist - I am currently fully booked, with new engagements onboarding from early 2027. Get in the queue and I will reach out as slots open.

Web & API penetration testing from CyberPOPE - OWASP Web & API Top 10 coverage, fixed price after scoping, verification round included. See full scope and pricing.