Skip to content

ISO 27001, SOC 2, the DPDP Act and manual VAPT. Book a Free Scoping Call

VAPT

How to Scope a Web Application and API Penetration Test

To scope a web application and API penetration test, write down every host, environment and API definition in scope, the roles and tenants the tester will hold, the limits they must respect, and what is excluded. SecureRoot turns that list into signed Rules of Engagement before testing starts. The roles, features, endpoints and authentication schemes in it are what set the price inside SecureRoot's published band of ₹50,000 to ₹4 lakh per surface, retest included. A scope is also a boundary: anything left off it is untested, so the work of scoping is mostly deciding, in writing, what an attacker could reach that you have not yet listed.

Request an assessmentContact SecureRoot

About this guide

Written by SecureRoot Risk Advisory LLP.

Step one

List every host, environment and API in scope

A tester can only test what the scope names. Start with an inventory, not with a test type.

  1. 01

    Name each URL and the environment it belongs to

    List the application hostnames, the API base URLs and any admin console, each marked as production, staging or another environment. If the same application runs in two environments, say which one is the target and how far it differs from the other.

  2. 02

    Hand over the API definition you have

    SecureRoot works from an OpenAPI or GraphQL schema, a Postman collection, or captured client traffic, in roughly that order of usefulness. The OpenAPI Specification is a language-agnostic way to describe HTTP APIs, which is why a current file shortens mapping. Out-of-date documentation is normal and not a blocker: it is reconciled against real traffic during reconnaissance.

  3. 03

    Include the versions and endpoints you would rather forget

    Improper Inventory Management is its own entry (API9:2023) in the OWASP API Security Top 10, because old API versions and debug endpoints go unnoticed. If a v1 is still routed, or an endpoint was retired from the interface but not from the server, put it on the list or exclude it deliberately.

  4. 04

    Mark the components you do not own

    Note the payment gateway, identity provider, CDN, email or SMS service and any partner API the application calls. You can authorise testing of your own systems; for someone else's, you need their permission or an exclusion. See the section on third parties below.

Step two

Decide between authenticated and unauthenticated testing

Unauthenticated testing shows what anyone on the internet reaches: login, registration, password reset, public pages and any API route that answers without a token. Authenticated testing shows what a signed-in user can do that they should not, which is where access-control and business-logic flaws sit. The OWASP Web Security Testing Guide treats authentication, authorisation, session management and business logic as separate testing categories, and most of them need an account to test at all.

For most applications the answer is both. SecureRoot's web application test runs anonymously and with the roles you provide, and its API test needs accounts because authorisation testing is comparative: without a second identity there is nothing to cross.

Step three

Choose the roles and tenants the tester will hold

Roles are the item that most often delays a start. Decide them early.

  • Web applications: at least two accounts at different privilege levels, and ideally two at the same level, so the tester can try to reach one user's data from the other.
  • APIs: SecureRoot asks for at least two accounts per role and two separate tenants, so object identifiers collected in one tenant can be replayed with the other tenant's token.
  • Approval chains, tenant boundaries and admin consoles: accounts on both sides of each one.
  • Every role you add enlarges the access-control matrix the tester has to walk, so list the roles that exist, then decide which ones matter rather than including all of them by default.
  • Seed the accounts with representative data. An empty account has no objects to cross.

The practical detail of creating these accounts is in the help article on preparing test accounts and staging.

Step four

Pick staging or production, and set rate limits

SecureRoot prefers staging, provided it mirrors production in code, configuration and roles. A staging environment that lags a release, runs debug settings or holds a much thinner dataset produces findings you cannot act on and hides ones you needed. Say what differs, and whether staging carries the same authorisation code as production.

When production is the only realistic target, which is common where integrations cannot be reproduced elsewhere, testing runs in agreed windows, destructive actions stay off the table, and a line stays open to your team throughout. In practice that means agreeing in advance:

  • which accounts and records are the tester's to touch;
  • that there is no mass data creation;
  • that payment and notification paths reaching real customers are not exercised;
  • the request rate the tester may send and the testing windows.

Rate limits deserve their own line. Unrestricted Resource Consumption is entry API4:2023 in the OWASP API Security Top 10, so whether limits exist and hold is part of the test. Where a test would be destructive, SecureRoot demonstrates it at small scale and describes the rest rather than running it, and keeping production out of bounds entirely is a scoping decision you can make.

Step five

Check third-party and cloud provider permissions

You can authorise testing of what you own or control. If the application runs on a public cloud, the provider's own policy sets the limits on top of your authorisation, and each one words it differently. Read the current version for each provider in scope:

  • AWS lets customers test a listed set of services, including EC2, API Gateway, Lambda, CloudFront, RDS and Elastic Load Balancers, without prior approval. It prohibits DoS and simulated DoS, port and protocol flooding, and request flooding, including login and API request flooding. Testing a service outside the list means working with AWS Support or your account representative.
  • Microsoft's rules of engagement confine encouraged testing to your own tenant or assets you are explicitly authorised to test, and prohibit denial-of-service testing and network-intensive fuzzing or automated testing that generates excessive traffic.
  • Google Cloud says you do not need to contact Google before testing your own Cloud Platform infrastructure, provided the testing follows its Acceptable Use Policy and Terms of Service and affects only your own projects.
  • Third-party services your application calls (payment gateway, identity provider, a partner API) are not yours to authorise. Exclude them, or get the owner's written permission. How your application handles what they return is still yours to test: OWASP lists Unsafe Consumption of APIs as API10:2023.

These policies change. The rate you agree in the rules of engagement has to sit inside the provider's limits as well as your own.

Step six

Write the exclusions down

An exclusion is not a gap if it is deliberate and written. Typical ones:

  • hosts, paths or API versions that are out of scope, by name;
  • actions that are off limits: denial of service, load testing, mass data creation, messages to real customers;
  • data the tester must not open or export, and how any data seen in passing is handled;
  • third-party services you cannot authorise;
  • social engineering and physical testing, which are separate test types rather than part of a web or API test.

Step seven

Agree the rules of engagement

The rules of engagement are the written version of everything above. In SecureRoot's web and API methodology, scoping ends in a signed Rules of Engagement that records the targets and environments, the test accounts for each role and tenant, the off-limits actions and data, the rate limits, the testing windows, and the escalation contacts on both sides. NIST SP 800-115 is the public reference for planning and conducting technical security tests if your team wants one to measure a vendor's planning against.

Two things are worth settling in the same document: who on your side can pause testing, and how a critical finding reaches you before the report does.

Beyond a scoping call, the demand on your team is light: provisioning accounts, a short walkthrough of anything unusual in the application, and someone reachable while testing runs.

Effort and price

What drives effort, and what does not

SecureRoot prices testing per surface, and a web application and its API are separate surfaces. Where an engagement lands inside the band is the size of the surface, not a rate card.

  • Web application: the number of user roles, features and endpoints. A workflow carrying state, money or approvals takes longer than a static surface of the same page count.
  • API: the number of endpoints, tenants and authentication schemes. Broken object-level authorisation is one test per object type, per role, per tenant, so it grows quickly.
  • Least important: raw page count. A sitemap alone tells a tester little.

The published band is ₹50,000 to ₹4 lakh per surface with the retest included, and the published timeline is 1 to 3 weeks of testing, plus a retest window after your fixes. SecureRoot confirms scope, timeline and a fixed price in writing once scoping is done.

Whether the API needs its own test: if it is reachable by anything other than your own front end, yes. A web or mobile test exercises the requests the client knows how to make, and API flaws usually sit in the requests a client would never send.

Scope boundaries

What this does not cover

  • A penetration test covers the scope written in the rules of engagement and nothing else. Hosts, versions and roles left off the list are untested.
  • You must hold the authority to permit testing of every host in scope. SecureRoot cannot authorise testing of a cloud provider's shared infrastructure or of third-party services your application calls.
  • Denial-of-service and load testing are not part of a web or API penetration test, and the major cloud providers restrict them.
  • A penetration test is not a source code review. Flaws visible only in code, including how secrets are handled, are covered by secure code review.
  • SecureRoot delivers internet-facing testing remotely. A staging environment that is not reachable from the internet needs an agreed access route, raised at scoping.
  • A test is a point-in-time result. It does not guarantee the absence of vulnerabilities or compliance with any standard. SecureRoot is not CERT-In empanelled; if a regulator or customer requires a report from an empanelled auditor, settle that before choosing a provider.

Questions

Common questions

  • Can we scope an API test without an OpenAPI file?

    Yes. SecureRoot can work from a GraphQL schema, a Postman collection or captured client traffic, and reconciles out-of-date documentation against real traffic during reconnaissance. A current definition shortens mapping, but its absence is not a blocker.

  • Do we need to tell our cloud provider before a web or API test?

    Usually not for testing your own resources, but read the current policy. AWS lists the services customers can test without prior approval, Microsoft confines testing to your own tenant, and Google Cloud says you need not contact it if you follow its Acceptable Use Policy and Terms of Service and affect only your own projects. All three restrict denial-of-service testing.

  • Is our web application test enough to cover the API behind it?

    Not if the API is reachable by anything other than your own front end. Partner and machine-to-machine integrations have no front end at all, and the API flaws that matter are usually in requests the client never sends. Scope the API as its own surface.

  • How many test accounts do we need?

    For a web application, at least two at different privilege levels and ideally two at the same level. For an API, SecureRoot asks for at least two per role and two separate tenants.

Primary Sources

Where the Figures on This Page Come From

Every deadline, threshold and control count above is taken from the instrument itself. These are links to the primary text, not to a summary of it.

Related

Services and help that go with this

Send us your scope, or the start of one

Share the hosts, API definition and roles you have, and SecureRoot will turn them into written Rules of Engagement with a fixed price and timeline.

Request an assessmentContact SecureRoot