Customer-facing application
Assess the workflows, roles, tenant boundaries, sensitive records, and privileged actions that carry the product's real risk.
Map the application scope
Web application penetration testing
Test the browser workflows an attacker would actually abuse.
Manual web application penetration testing for identity, access, business logic, data handling, and integration risks. Findings are validated, bounded, and written for remediation.
Engagement fit
When a web application pentest is the useful next step.
The test should answer a product or assurance question, not exist as an isolated technical exercise.
High-risk change
Focus testing on a new identity flow, payment path, administrative feature, file workflow, or integration before a release decision.
Discuss the releaseBuyer or stakeholder request
Define the application boundary, testing period, evidence, exclusions, and closure record needed to answer a concrete assurance request.
Inspect the sample reportManual coverage
Coverage follows the application's trust boundaries.
Testing starts with how people, browsers, back-end services, and third parties exchange authority and data. Tools support discovery, while exploitation and impact are validated manually.
Browser workflows
Multi-step actions, state transitions, navigation assumptions, client-controlled values, cross-origin behavior, caching, and browser-side security controls.
Authentication & session
Registration, sign-in, recovery, MFA, SSO, session creation and invalidation, remember-me behavior, token exposure, and account enumeration.
Access control
Object ownership, tenant separation, horizontal and vertical privilege changes, hidden functions, administrative actions, invitations, and role transitions.
Business logic
Sequence bypass, replay, duplicate actions, race conditions, limit manipulation, approval abuse, price or credit changes, and invalid state transitions.
Input & server-side handling
Injection paths, request forgery, unsafe parsing, template or command execution risks, redirects, error behavior, and inputs forwarded to downstream systems.
File features
Upload, download, preview, import, export, archive, media processing, content validation, storage authorization, and active content risks.
Data exposure
Sensitive fields in pages, responses, source maps, logs, exports, caches, predictable identifiers, verbose errors, and unintended metadata.
Integration trust
Webhooks, callbacks, OAuth connections, payment or messaging providers, partner portals, signed requests, secrets handling, and third-party data boundaries.
Scoping inputs
Define what must be tested before the window is booked.
A URL alone cannot describe the effort or the safety controls. These inputs turn an application into a reviewable scope.
| Input | What to provide | Why it changes the test |
|---|---|---|
| Application boundary | Hosts, environments, major modules, supporting APIs, and administrative interfaces | Establishes which routes, components, and trust boundaries are authorized |
| Roles & tenants | Test accounts for each relevant role, tenant, team, or ownership state | Authorization coverage grows with meaningful role and tenant combinations |
| Identity flows | Local login, SSO, MFA, passwordless, recovery, invitations, and account linking | Each identity path introduces distinct session states and abuse cases |
| Critical workflows | Payments, approvals, exports, file handling, messaging, billing, or privileged changes | Manual scenario testing concentrates on actions with material business impact |
| Integrations | Third-party services, callbacks, webhooks, shared secrets, sandboxes, and test accounts | Clarifies what can be exercised safely and which provider assets remain excluded |
| Environment readiness | Stable build, test data, documentation, logging contact, rate limits, and known constraints | Reduces discovery friction and supports safe validation of complex paths |
| Decision & deadline | The release, customer, procurement, or risk decision the report must support | Shapes priorities, reporting depth, review time, and the required closure evidence |
Testing path
From authorization to verified closure.
Each phase leaves an inspectable record, so the application boundary, proof, and remediation status do not depend on memory.
Fix the boundaries
Confirm written authorization, hosts, roles, allowed techniques, prohibited actions, test window, contacts, evidence handling, and stop conditions.
Map the workflows
Review architecture and product context, establish role and tenant states, and identify the paths where authority or sensitive data changes hands.
Exercise abuse cases
Combine structured coverage with manual hypotheses, then validate exploitability using controlled accounts and the minimum evidence needed.
Report and re-test
Deliver reproducible findings and remediation guidance, discuss the result with engineering, and verify agreed fixes in the bounded re-test window.
Safety & exclusions
Strong evidence inside explicit operating rules.
The default is controlled testing, minimal-impact proof, and an immediate escalation path for urgent findings.
Defined before testing
Authorization and safety controls
- Named in-scope hosts, environments, roles, and accounts
- Approved test window, rate limits, and escalation contacts
- Rules for customer data, synthetic data, logs, and evidence
- Stop conditions for instability or unexpected impact
- Minimum-impact proof using controlled objects where possible
- Immediate notification at the agreed severity threshold
Not implied
Separate approval or separate scope
- Denial-of-service, load, or stress testing
- Social engineering or physical access
- Third-party systems without their written authorization
- Source-code review unless it is explicitly included
- Infrastructure, mobile clients, or APIs outside the named boundary
- Features or environments introduced after scope approval
Deliverables
Evidence for the engineer and context for the decision-maker.
The deliverable should make each issue reproducible, explain why it matters, and give the team a practical route to closure.
Validated technical records
Each reported issue includes affected scope, prerequisites, reproduction steps, bounded evidence, impact, severity rationale, and remediation guidance.
Executive risk summary
A concise view of the tested boundary, important themes, limitations, and decisions the result can reasonably support.
Remediation walkthrough
A working session connects the evidence to application behavior, answers engineering questions, and clarifies fix priorities.
Bounded re-test update
Agreed fixes are checked against the original evidence and recorded as fixed, partially fixed, not fixed, or not re-tested.
Readiness & timing
A stable scope makes testing time more useful.
No duration is promised before the boundary is reviewed. The confirmed schedule depends on the application and the access needed to test it safely.
What helps the test start cleanly
A stable build, working accounts for each role, seeded test data, application and API notes, known limitations, an escalation contact, and access that has been verified before the window.
What changes the timeline
More roles or tenants, complex SSO, broad integrations, production-only controls, sparse documentation, unstable builds, tightly restricted windows, and deeper reporting or review needs.
What can run in parallel
Procurement, agreement review, test-account preparation, architecture questions, and report audience alignment can progress while the final scope is being confirmed.
What should wait
Testing does not begin until authorization, rules of engagement, scope, access, and contacts are complete. Material releases during testing may require a revised boundary.
Related paths
Choose the surface that matches the risk.
Web interfaces and APIs often share trust boundaries, but each needs its own test design and access model.
API penetration testing
Focus on object and function authorization, data exposure, tokens, resource controls, inventory, and downstream service trust.
Review API testingCompare engagement shapes
See the core web and API sprint, focused release testing, adjacent surfaces, included work, and explicit exclusions.
Explore the services hubPrepare the boundary
Turn roles, workflows, identity, integrations, environment, and decision deadline into a private draft brief.
Use the scope plannerWeb pentest FAQ
Questions to settle before scoping.
Clear answers here prevent hidden assumptions from entering the test window.
What is included in a web application penetration test?
The final coverage follows the agreed application boundary. It can include browser workflows, authentication, sessions, role and tenant access, business logic, input handling, file features, sensitive data exposure, browser controls, and authorized integrations. The statement of work lists the included hosts, roles, and exclusions.
Can the test include production?
Production can be considered when it is authorized and appropriate. The rules of engagement must define safe techniques, customer-data handling, rate limits, monitoring, escalation, and stop conditions. Riskier cases may require a representative non-production environment.
Is this only an automated vulnerability scan?
No. Tools can support mapping and repeatable checks, but the assessment follows workflows and validates exploitability manually. Unverified scanner output is not presented as a confirmed finding.
Does source-code review come with the test?
Not by default. Source-assisted testing or a dedicated code review can be scoped when repository access is available and it would materially improve coverage. The agreement states which approach is authorized.
How are fixes verified?
A bounded re-test checks agreed findings against the original evidence in the defined window. The update records the observed status and any remaining exposure without claiming that the entire application is vulnerability-free.
What is needed for an accurate quote?
Share the application boundary, environments, supporting APIs, roles, tenants, identity flows, critical workflows, integrations, known constraints, desired test window, report audience, and the decision the assessment must support.
Define the test
Turn the application into a clear, authorized scope.
Start privately in the planner or share the product boundary and decision deadline for a scope review.