Web application penetration testing
Human-led testing of the application your customers actually use: authentication, authorisation, business logic and the paths that chain them. Evidence and a retest, not a scanner PDF.
- Human-led
- Every reported finding reproduced
- Retest included
-
Human testers leadTooling widens coverage only
-
Scoped firstRoles, tenants and environments
-
Retest includedWithin 6 months, up to 10 issues
-
Replayable evidenceSteps a developer can follow
What we test
Time goes where a low-privilege user, a neighbouring tenant or a stolen session could change data or money.
Authentication and sessions
Login, MFA, sessions and account recovery.
Details
Login, MFA bypass conditions that are actually reachable, session expiry, logout, remember-me, and account recovery. We look for tokens that outlive the session and recovery flows that skip the real user.
Authorisation
Role and object boundaries the UI hides.
Details
Vertical and horizontal boundaries. Object identifiers in the URL, the body or a hidden field. Admin functions that the UI hides but the request still accepts.
Business logic
Checkout, refunds, approvals and other workflows.
Details
Multi-step workflows: checkout, refunds, approvals, invitations, feature flags and state machines. Race conditions only where a safe proof shows impact.
Tenant isolation
One customer reaching another’s records.
Details
B2B SaaS patterns: one customer reading or writing another’s records, shared caches, exports, search, and support impersonation that never drops privilege.
Injection and file handling
Injection, uploads and previews that become a real path.
Details
SQL, command, template and XSS only when they become a real path. Uploads, imports and previews checked for type confusion and storage that other users can fetch.
Integrations
Webhooks, SSO hand-off and the API the UI calls.
Details
Webhooks, SSO hand-off, admin consoles and the API the UI calls. If the API is a separate product, it is scoped on the API page rather than assumed.
How depth is decided
A web assessment follows the product, not a generic checklist. We agree roles, tenants and environments first, then spend the time where a low-privilege user, a neighbouring tenant or a stolen session could change data or money.
Depth follows the architecture and the rules of engagement. A long list of informational headers without an exploit narrative is not the goal.
Why manual testing still decides the result
Scanners are useful for known classes and for hygiene. They are weak at role confusion, multi-step abuse, feature-flag edges and tenant breaks that only appear when someone thinks like an attacker against this product. Modern web apps are API-backed, permission-heavy and released often. A useful report says what a specific role could achieve, in product language, and what engineering should change.
Read more
PoCForge documents reproduction clearly enough for a developer who was not in the test to replay it, then retests the fixes that land within 6 months of the original test (up to 10 issues). Closure is a status, not a promise that the whole application is “secure”.
Deliverables
- Executive summary a customer questionnaire can rely on, with severity matched to real impact.
- Technical findings with reproduction steps and the role used.
- Remediation notes written for engineering owners, not a generic control catalogue.
- Retest results for fixes that were in scope and ready in the window.
Who this fits, and what it is not
A good fit
- Product-led SaaS, fintech and platform teams
- Before an enterprise review
- After an authentication rewrite
- As one part of a wider programme
Not what this is
- A vulnerability-scan subscription
- A source code review
- A red-team exercise
Assumed-breach objectives are scoped separately; see the assumed-breach case study and say so when you write.
Full description
Product-led SaaS, fintech and platform teams that need a serious pass before an enterprise review, after an authentication rewrite, or as one part of a wider programme. It is not a vulnerability-scan subscription, not a source code review, and not a red-team exercise. Assumed-breach objectives are scoped separately; see the assumed-breach case study and say so when you write.
Investment
Price moves with roles, tenants, environments and whether API testing is included. Use the starting prices for a global starting point and the India cost guide for India pricing. India commercial packaging is on VAPT services in India. We do not publish a day-rate that pretends every application is the same size.
Indicative global range often discussed at scoping: comparable manual web work is quoted from the live starting prices. Final quotes stay scope-based.
A report can support SOC 2 and ISO 27001 evidence. It does not certify the company, and it does not replace the auditor. PoCForge is not a certification body and does not claim CERT-In empanelment. If a contract names an empanelled auditor, read when CERT-In empanelment is required and check the official list before you shortlist.
Pair web with API security testing when the UI is a client of a wider API, with desktop / Electron when a companion app holds privilege, or with cloud when the question is the account around the app rather than the app itself.
Scope and rules
- Scope workshop. Applications, environments, roles, tenants, exclusions and what a useful outcome looks like.
- Rules of engagement. Windows, contacts, production limits, data handling and how we escalate if we touch live customer data.
- Discovery. Map the agreed surface. Targeted tooling where it saves time, not as the finding list.
- Manual testing. Authorisation and business logic first. Injection and configuration where they change impact.
- Report. Severity, evidence, reproduction and remediation aimed at the team who owns the code.
- Retest. In-scope fixes verified within 6 months of the original test (up to 10 issues), with an updated closure note.
SaaS tenant isolation
Anonymised multi-tenant review: the approach, the finding classes and how the retest was run.
Read the case study →- Human testers lead; tooling widens coverage
- Every finding in the report was reproduced
- Retest within 6 months (up to 10 issues)
Related
Frequently asked questions
Do you only run automated scanners?
No. Tooling supports coverage. Findings that matter are reproduced by a tester, with evidence and an impact note your engineers can act on.
Do you claim CERT-In empanelment?
No. PoCForge does not claim CERT-In empanelment. If procurement requires it, use the CERT-In guide and verify the official list.
Where is India pricing published?
On the India web page and the India cost guide. This page is the global method.
Can web testing include the API and cloud account?
Yes, when you scope them. The UI and its private API are often one engagement. A public API used by other clients, or an AWS account review, is called out so the rules stay clear.
Is a retest included?
Yes, for fixes that are in the agreed scope and ready inside the retest window. New features shipped during that window are a new scope, not a silent expansion.
Scope a web application assessment
Tell us the app, the roles and the environment. We will propose a test plan before any active work.
