A first look at the whole app
Review the main workflows, user roles, customer boundaries, and sensitive records together.
Map the application scope
For product and engineering teams
Web application
Web application
penetration testing.
Web application penetration testing is a manual security assessment of a web app: its sign-in, permissions, business logic, and data handling. Balhence checks for weaknesses across the agreed scope, confirms each reported finding by hand, and gives engineers reproduction steps, impact, and practical remediation guidance.
When it helps
When web application penetration testing helps
A launch, a security review, or a change to a sensitive feature can each call for a different scope.
A change you need to get right
Focus on a new login flow, payment feature, admin tool, or integration before it goes live.
Discuss the releaseA customer asks for a pentest
Work out what needs testing, when the report is due, and which evidence and re-test results the customer needs to review.
View the sample reportWhat we test
What we test in a web application
We follow how people use the application and check the controls behind those actions. Each reported finding is confirmed by a tester.
Browser workflows
What happens across a multi-step action? We check state changes, browser storage, caching, cross-origin behavior, and assumptions made by the interface.
Private content needs the same access rules at the application and cache layers. Our anonymized cache data exposure story explains why a working login check can leave that boundary untested.
Authentication & session
Registration, sign-in, recovery, MFA, and SSO. We also check how sessions start, expire, and end when access is revoked.
Session ownership is a separate question from successful sign-in. The session isolation field note illustrates why two controlled browsers and their application state matter when assessing that boundary.
Access control
Can each role reach only the records and actions it should? We include tenant separation, invitations, admin functions, and role changes.
Business logic
Payments, credits, approvals, and other sensitive workflows. We check whether their rules survive repeated actions, unexpected ordering, or overlapping work.
Input & server-side handling
How the server parses and uses incoming data, including injection risks, request forgery, redirects, errors, and data passed to other systems.
File features
Uploads, previews, imports, exports, and downloads. We look at content checks, processing, and who can access the stored files.
Data exposure
Check what appears in pages, API responses, exports, caches, source maps, and errors. Sensitive information can turn up outside the main screen.
Integration trust
Webhooks, OAuth connections, payment providers, and partner services. We review the checks made when information crosses between them.
Web app testing for SOC 2 and other audits
Agree the tested systems with the boundary in your audit or customer review. We provide human-verified findings, coverage limits, and an agreed re-test record for the reviewer to evaluate. See SOC 2 penetration testing.
Planning the scope
Planning your web application pentest scope
These details help us agree on the coverage, estimate the work, and book a test window that fits. Use the application pentest scoping guide if you are gathering this for the first time.
| 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 |
Web application role and workflow worksheet
Before requesting a quote, describe expected permissions for your critical workflows. This illustrative document app uses synthetic files and three roles in one workspace. Adapt the rows to your product; the agreed scope determines which relationships are assessed.
| Role and workflow | Expected permission | Preparation needed |
|---|---|---|
| Viewer / shared file | Read assigned files; no editing or approval | Viewer account and a synthetic shared file |
| Editor / draft changes | Edit assigned drafts; approval requires another role | Editor account and draft ownership rules |
| Approver / publication | Approve eligible drafts within the assigned workspace | Approver account and documented approval states |
| Removed member / previous files | Access ends according to the documented revocation policy | A controlled removed account and session expectations |
Record the intended rule, test identity, and permitted data for each row. Use the pentest cost and scope guide to compare proposals with the same role coverage, reporting depth, and re-test terms.
OWASP web application testing methodology
We use the OWASP Web Security Testing Guide and OWASP Top 10 to inform coverage, then examine the business rules specific to your application. The report records the agreed scope, test methods, evidence, and limits.
How the test works
How the web application pentest works
The scope, findings, and agreed re-test results stay documented. Your team can see what we checked and what still needs attention.
Agree on the scope
Confirm written authorization, hosts, roles, allowed techniques, prohibited actions, test window, contacts, evidence handling, and stop conditions.
Map the workflows
Learn how your app works, what each role can do, and where permissions or sensitive data pass between users and services.
Check what can go wrong
Test the agreed coverage and follow up on potential issues. Use controlled accounts and collect only the evidence needed to confirm each finding.
Report and re-test
Walk your engineers through the findings and suggested fixes. If a re-test is included, check the agreed fixes in that window.
Safety & exclusions
Web application pentest authorization and safety
We agree on safe testing methods, keep the impact of each check small, and set up a direct channel 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
What you get
What you get from a web application pentest
Each finding explains what went wrong, why it matters, how to reproduce it, and where to start with a fix.
Confirmed findings
Each issue includes affected systems, prerequisites, reproduction steps, evidence, impact, the reason for its severity, and fix guidance.
A summary for leadership
A short account of what was tested, the main risks, and the limits of what the results can tell you.
Time with your engineers
Walk through the findings, ask questions about the evidence, and discuss which fixes need attention first.
An update on agreed fixes
When a bounded re-test is included in the agreement, fixes are checked against the original evidence and recorded as fixed, partially fixed, not fixed, or not re-tested.
Getting ready
Web application pentest readiness and timelines
Working accounts, a stable build, and current documentation let us spend more time testing. We'll confirm the schedule after reviewing the scope and access.
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 services
Web application and API testing scope options
Web apps and APIs often share users and data. We can help you decide whether to test them together or focus on one.
API penetration testing
Focus on object and function authorization, data exposure, tokens, resource controls, inventory, and downstream service trust.
Review API testingSaaS penetration testing
Plan around tenant isolation, shared workspaces, SSO, integrations, and the evidence your next customer review needs.
Explore SaaS testingDraft your scope
Gather your app details, roles, integrations, and deadline in a private draft you can review before sharing.
Use the scope plannerWeb pentest FAQ
Web application penetration testing FAQ
A few common questions about coverage, access, and what happens after the report.
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.
How much does a web application pentest cost?
The quote depends on meaningful roles and tenants, workflow depth, supporting APIs, integrations, environment access, and reporting needs. Page counts alone do not describe that work. We confirm the scope, effort, exclusions, deliverables, and any re-test window in the proposal. Read the pentest cost and scope guide to compare proposals on the same basis.
How long does the test take?
We confirm a test window after reviewing the scope and checking access readiness. Your deadline needs to allow for testing, the report, engineering fixes, and any agreed re-test. Tell us whether it supports a release or a customer's review so we can discuss a workable sequence before you commit.
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?
When included in the agreement, 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.
Can I see how you explain an application security finding?
Start with the illustrative pentest report for the delivery format. Our redacted authorization field note shows how a denied read can coexist with an unsafe write, and how to explain the evidence limits. The field note is an anonymized teaching story, not a client endorsement or a published fix confirmation.
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.
Plan your test
Scope your web application penetration test.
A short description, the main roles, and why you need the test are enough to start the scoping conversation. Do not send credentials or customer data.