How to scope a web application and API penetration test

Most scoping problems show up late. A tester arrives on day one to find that the admin role has no test account, half the API is behind a gateway nobody mentioned, or the staging build is three releases behind production. The test still happens, but it covers less than everyone assumed, and the report says so in a footnote that the buyer’s reviewer reads first.

This guide sets out what to collect before you ask any provider for a quote. It applies whether you are a software company testing your own product or an agency testing a client’s application. Nothing here authorises testing. Testing starts only after a written scope is agreed and the system owner has signed an authorisation.

Start with why the test is needed

Before the inventory, write down the reason for the test and who will read the report. The answer changes the scope.

Trigger	What it usually means for scope
An enterprise prospect has sent a security questionnaire	Their reviewer may specify recency, coverage or tester independence. Ask for their requirements in writing before scoping.
A release changes authentication, roles or tenant isolation	Focus effort on the changed permission boundaries and the workflows that cross them.
SOC 2 or ISO 27001 audit preparation	The auditor decides what testing evidence is sufficient. Confirm their expectations on scope and cadence.
An AI feature gains retrieval sources or action-taking tools	Add the model-facing surface and the tools it can call. See the AI feature launch checklist.
An agency is handing a build to a client	Agree who owns the system, who signs authorisation and who receives the report before scoping.
A previous test left open findings	Decide whether this is a retest of named findings or a new assessment. They are scoped differently.

If a reviewer has asked for the test, find out whether they need a full report, an executive summary, or evidence that specific findings were fixed. That determines the deliverables, which in turn affects effort.

What to inventory

A domain list is not a scope. A tester needs to know what the application does, who can do it and where the boundaries between users sit. Collect the following.

Applications and front ends

Each web application by URL, with a one-line description of what it is for.
Customer-facing, admin and internal back-office interfaces listed separately. Admin panels are often where the highest-impact findings sit.
Any single-page application that talks to an API, and which API it talks to.
Mobile apps, if they share the same API. Mobile client testing is a separate scope item, but the API behind it belongs here.

APIs

Each API with its base URL (for example api.example.com), its type (REST, GraphQL, gRPC, SOAP) and whether it is public, partner-facing or internal.
The specification you have: OpenAPI or Swagger file, GraphQL schema, Postman collection, or nothing. A current specification lets the tester cover endpoints that no front end calls.
An honest endpoint count, or a range. If the specification is out of date, say so.
Versioned APIs. If v1 is still reachable alongside v2, both are attack surface.

Roles and privilege boundaries

Every role in the system: anonymous, standard user, power user, billing owner, tenant admin, support staff, platform admin.
What each role should and should not be able to do. A short permission matrix is ideal.
Any role that can impersonate another user, or act across tenants.

Roles drive effort more than anything else. Each additional role multiplies the number of “can this user do that?” checks.

Tenants

Whether the application is single-tenant, multi-tenant with shared data stores, or multi-tenant with separate stores.
How tenant identity is carried: subdomain, header, token claim, path segment.
At least two test tenants, so the tester can try to reach tenant B’s data from tenant A.

Cross-tenant access is one of the findings enterprise reviewers care about most. If you have tenants, plan to test isolation between them.

Environments

Every environment in play (production, staging, UAT, preview builds) and which one is proposed for testing.
Material differences between the test environment and production: feature flags, data volume, WAF rules, third-party integrations pointed at sandboxes.

Integrations and third parties

Inbound webhooks, outbound API calls, OAuth or SSO providers, payment providers, email and file storage services.
Which of these are in scope for testing and which are excluded because you do not own them. Testing a third-party service usually needs that party’s permission, not yours.
Service accounts and API keys the application holds, and what they can reach.

Critical workflows and sensitive data

The workflows that would hurt most if abused: sign-up and invitation, password reset, payment, refunds, data export, account deletion, role changes.
The types of sensitive data held: personal data, payment data, health data, credentials, customer-uploaded files.

These shape where manual effort goes. A tester with a list of critical workflows will spend time on business logic rather than repeating generic checks.

What drives effort (and therefore cost)

Prices vary between providers and scopes. ZenoPentest publishes starting prices and fixes the figure after reviewing a written scope. These factors move the estimate.

Factor	Why it adds effort
Number of roles	Each role adds authorisation checks against every sensitive function.
Number of tenants and the isolation model	Cross-tenant testing needs paired accounts and checks on every object reference.
API endpoint count and specification quality	Undocumented endpoints have to be discovered before they can be tested.
Workflow complexity	Multi-step flows (approval chains, payments, invitations) need manual logic testing.
Number of distinct front ends	An admin panel and a customer portal are separate attack surfaces even on one API.
Integrations in scope	Webhooks, SSO and OAuth flows each have their own failure modes.
Environment readiness	Missing accounts, blocked IPs or broken builds consume testing days.
Report and evidence requirements	A coverage record, a shareable summary or a reviewer readout each take time.
Retest arrangements	Verifying fixes is separate effort and should be agreed in the proposal.

Two things do not drive effort as much as buyers expect. Page count matters little: a 400-page marketing site with one login form is small. Raw request counts in a report say nothing about depth either. What matters is how many permission boundaries and workflows need a human to reason about them.

Black box, grey box or white box

These terms describe how much the tester is told before starting.

Approach	Tester has	Good for	Trade-off
Black box	A URL and nothing else	Seeing what an unauthenticated outsider can find	Much of the time goes on discovery. Authenticated functions may never be reached.
Grey box	Test accounts in each role, API specification, architecture notes	Most web and API assessments	Needs preparation from you. Covers far more in the same time.
White box	All of the above plus source code access or design documents	Complex authorisation logic, cryptography, high-risk features	Needs secure code access and more reviewer time.

For most software companies and agency client projects, grey box gives the best coverage per testing day. Real attackers are not limited to a fixed testing window, so withholding information from the tester mostly means less of the application gets tested. If you want an unauthenticated perspective as well, include it as one part of a grey-box scope.

Staging or production

There is no universal answer, but there are clear trade-offs.

Staging or UAT is usually safer. Destructive tests, mass account creation and payment flows can run without touching real customers. The risk is drift: if staging differs from production in configuration, data or integrations, findings may not transfer and real issues may be missed. Record the differences.

Production shows the real configuration, but carries operational risk. If you test production, agree:

which actions are off-limits (sending real emails, charging real cards, deleting data);
rate limits and testing hours;
a stop contact who can be reached during the window;
how critical findings are reported while testing is still running.

Some teams test most functionality in staging and run a narrower configuration and access-control check against production. That combination should be written into the scope so the report states which environment each result came from.

Test accounts and access

Prepare these before the test window opens. Missing access is an avoidable way to lose testing time.

At least one account per role, and two accounts in the roles that matter most so horizontal access can be tested.
At least two tenants, each with its own admin and standard user.
Realistic but synthetic data in each tenant: records, files, invoices, messages. An empty tenant hides object-reference bugs.
MFA arrangements: either test accounts with MFA the tester can complete, or an agreed exemption recorded in the scope.
IP allow-listing or VPN access, if the environment is restricted.
Any API keys or OAuth clients the tester needs to call the API directly.

Send credentials through a separately agreed secure channel. Do not put them in an enquiry form, a scope document or email.

What a good scope record says

The scope record is the document the report refers back to. Someone who was not in the scoping call, such as your customer’s security reviewer or your auditor, should be able to read it and understand what was tested. It should state:

Purpose and audience. Why the test is being done and who will read the report.
Parties. The system owner, the commissioning party (if different, such as an agency), the testing provider, the assessment lead named in the proposal and the authorisation signatory.
Assets in scope. URLs, API base paths, specification version and build or release identifier.
Roles and tenants. Which roles and tenants will be tested, with the test accounts provided.
Environment. Which environment, and how it differs from production.
Methods. Grey box or otherwise, testing approach and any methods excluded (denial of service, social engineering, physical access).
Exclusions. What is out of scope and why: third-party services, legacy endpoints, features not yet built.
Window and contacts. Test dates, hours, stop contact, critical-finding notification channel.
Deliverables. Full report, coverage record, executive summary, readout, and any retest arrangement agreed in the proposal.
Evidence handling. Where evidence is stored, who can access it, and when it is deleted.

During delivery, the coverage record is updated with what was actually tested, on which build, and anything that could not be tested and why. That gap list is useful. A report that says “the billing admin role could not be tested because the account was not provisioned” is honest. One that stays silent is a problem when a reviewer asks.

Common scoping mistakes

Scoping by domain only. “Test app.example.com” says nothing about the twelve roles and two hundred endpoints behind it.

Forgetting the admin side. Internal admin and support tools often have broad permissions and less hardening. Leaving them out leaves out the highest-impact paths.

One account per role. Without two accounts at the same level, horizontal access (user A reading user B’s records) cannot be tested properly.

Empty test tenants. If there are no invoices in the tenant, the tester cannot check whether another tenant’s invoices are reachable.

Scoping a moving target. If the build changes daily during the test window, findings may not reproduce and fixes may land mid-test. Freeze or tag a build.

Assuming third parties are covered. Your payment provider, identity provider or hosting platform has its own testing rules. Your integration with them can be tested. Their platform usually cannot without their permission.

Leaving retest undefined. If you need evidence that findings were fixed, agree in the proposal what a retest covers, how it is requested and what counts as new scope.

Not asking the reviewer first. If the report is for a customer’s security team, ask what they need before scoping. Discovering after the test that they wanted tenant isolation coverage, or a named independent tester, costs a second engagement.

Scan, manual pentest or PTaaS

These are different services. Each has a fair use.

	Automated vulnerability scan	Manual penetration test	PTaaS (pentest as a service)
What it does	Runs known checks against reachable surfaces	A tester reasons about the application’s roles, logic and boundaries, using tools to support manual work	A platform-delivered testing model, often with an ongoing portal, scheduled or on-demand testing and integrations
Strong at	Known vulnerabilities, missing patches, misconfigurations, regular coverage between tests	Authorisation flaws, tenant isolation, business logic, chained issues	Repeat testing cadence, findings tracking, workflow integration
Weak at	Logic, multi-step workflows, permission boundaries between users	Continuous coverage between engagements	Varies by provider. Depth depends on the manual effort behind the platform.
Typical output	Long list of automated results	Narrative findings with reproduction steps, impact and fixes	Portal findings plus reports, depending on the provider

A scanner is a sensible control to run regularly, and many teams should. It does not answer “can a tenant admin in one organisation read another organisation’s data?”. A manual test is designed to. PTaaS models vary widely, so ask any provider, including ZenoPentest, how much of the work is manual, who performs it and what the report contains.

If your reviewer asked for a penetration test, a scan report alone is unlikely to satisfy them. If you need continuous coverage between manual tests, a scanner or a PTaaS arrangement may complement a scoped test rather than replace it.

Next steps

Work through the pentest readiness checklist to confirm accounts, data and contacts are ready.
Read how ZenoPentest approaches scoping and authorisation, API testing and authorisation and tenant isolation.
If the report is going to a customer’s security team, read what enterprise reviewers expect from a pentest report.
When you have an inventory, start a scope. Agencies scoping a client project can use the partner enquiry. No testing starts from an enquiry: a written scope and signed authorisation from the system owner come first.