A useful web application pentest scope is more than a domain and login. It tells the provider what product boundaries, identities, functions, workflows and connected services must be tested, under which environment and safety constraints.

The checklist should make quotations comparable while preserving room for security discovery. It is a baseline of known coverage, not an instruction to ignore reachable assets that must be reported through change control.

Treat the scope as a controlled product map shared by the buyer, provider and operations team. It should be detailed enough to expose missing accounts and integrations before testing, yet readable enough for a risk owner to understand what assurance the final report can and cannot support.

Identify product and hostname boundaries

List customer, partner, employee and administration applications with canonical URLs and ownership. Include alternate hosts used for login, uploads, static content or regional delivery.

Distinguish first-party targets from shared platforms and third parties. Record which reachable hosts require separate authorization rather than assuming a wildcard covers every dependency.

  • Primary and alternate domains.
  • Administration and support portals.
  • Upload, download and content hosts.
  • Regional, legacy and preview applications.

Fix environments and builds

State production, staging, test or review environment and the release identifier. Describe material differences in data, controls, integrations and configuration.

Define the change cut-off and what happens when a new build arrives. Findings and retest evidence must identify the version actually tested.

  • Environment URLs and purpose.
  • Version, commit or release tag.
  • Production-equivalence differences.
  • Build-change and restart rule.

Inventory pages by function

Page count alone is weak for single-page applications. List routes, screens and components with the operation they enable, including hidden menus and role-specific views.

Group repeated templates while preserving unique server actions, input types and authorization decisions. Ask the provider to state sampling rather than silently treating similar appearance as identical control.

  • Anonymous and authenticated routes.
  • Create, read, update and delete functions.
  • Search, export, report and bulk actions.
  • Error, preview and legacy routes.

Map roles, tenants and object ownership

Define anonymous, customer, partner, support and administrator roles, custom permissions and delegated access. Provide multiple accounts when peer or cross-tenant checks matter.

Document object relationships: owner, collaborator, organisation member, outsider and platform operator. Authorization testing requires these contrasts, not one privileged login.

  • Role and permission matrix.
  • Representative tenants or organisations.
  • Owned, shared and foreign objects.
  • Pending, suspended and closed states.

Include the authentication lifecycle

Scope registration, invitation, login, MFA, SSO, recovery, password change, step-up, logout and session revocation. State identity providers and test-account control.

Include transitions such as role change, email change and account deletion. Authentication strength at login does not prove that sessions and privileges change correctly later.

  • Local and federated login.
  • Recovery and enrolment.
  • Session lifetime and concurrent devices.
  • Privilege and account lifecycle.

List critical business workflows

Name transactions whose abuse creates monetary, privacy, safety or contractual harm. Provide expected state transitions, roles and final authoritative effects.

Include alternate sequences, retries and administrative interventions. A provider can price meaningful business-logic work only when critical journeys are visible.

  • Onboarding and approval.
  • Payment, refund and entitlement.
  • Document sharing and export.
  • Closure, cancellation and exception handling.

Capture inputs and complex content

Inventory forms, files, archives, rich text, images, templates and data imports. Record accepted formats, size limits and processing services.

Include server-side rendering, conversion, preview and download paths. The security boundary may extend beyond the form that receives the input.

  • File upload and retrieval.
  • Rich editors and markup.
  • Import and bulk data.
  • Server-side parsing or conversion.

Connect APIs and real-time channels

List APIs used by the browser, GraphQL endpoints, WebSockets, server-sent events and background polling. Decide whether direct API testing is included or handled by a linked scope.

Do not assume observing browser traffic covers systematic object, role and workflow testing. Assign ownership so the web and API workstreams do not leave a gap.

  • REST operations and versions.
  • GraphQL queries and mutations.
  • Real-time subscriptions or sockets.
  • Browser-to-service identity context.

Map integrations and trust transfers

Include identity providers, payment processors, analytics, support widgets, storage, webhooks and embedded third-party content. State which side of each integration may be tested.

Record tokens, redirects, callbacks and data flows at the boundary. Third-party exclusion should not remove testing of your application’s validation and use of returned data.

  • OAuth and SSO integrations.
  • Payment and messaging providers.
  • Webhooks and callback receivers.
  • Embedded scripts and content.

Include privileged and operational surfaces

Administration, support impersonation, feature flags, audit search and operational tools often carry the highest authority. Identify separate hosts and access prerequisites.

Scope approval and maker-checker logic. If direct testing is restricted, define source-assisted or demonstration evidence and state the assurance limitation.

  • Global and tenant administration.
  • Support and impersonation.
  • Configuration and feature management.
  • Audit, export and recovery operations.

Set safety, data and coordination rules

Define production versus non-production, rate ceilings, destructive exclusions, email and payment effects, designated data and stop contacts.

Complete accounts, allowlisting and readiness checks before the clock starts. Record how blocked time and unstable environments are handled.

  • Safe test identities and data.
  • Monitoring and emergency contacts.
  • Prohibited actions and third parties.
  • Cleanup and reconciliation.

Define coverage, reports and retesting

Require coverage status against the inventory, evidence standards, executive and technical reports, readouts and factual review.

State included retest cycles, window, eligible findings and closure criteria. The scope is incomplete if it defines discovery but not how verified remediation will be recorded.

Require the final coverage record to reconcile late discoveries and approved changes against the original baseline. That prevents a detailed initial inventory from becoming detached from what the tester actually completed.

  1. Attach the inventory and role matrix.
  2. Validate access and critical workflows.
  3. Reconcile exclusions and sampling.
  4. Approve evidence and retest acceptance.

Use the OWASP Web Security Testing Guide to structure test areas, the OWASP ASVS for control objectives and NIST SP 800-115 for assessment planning and rules.

Make web scope reflect business authority

A domain list says where the application lives; a real scope says who can do what, to whose data, in which state and through which connected service.

WIMD turns those relationships into inventories, matrices and acceptance criteria that vendors can price and testers can evidence.