Web Application Penetration Testing Services for Enterprises
Customers and staff use your web applications every day to log in, pay, apply and approve. One flaw in login or access control can expose accounts, data or money. A web application penetration test shows which flaws an attacker could actually use, so your team fixes those first.
What we test in a web application
Scope and prerequisites
Before testing starts we agree, in writing, the URLs and user roles in scope, the environment (production or a copy), any change freeze, and who to call if something looks wrong. For testing as a logged-in user, you provide one test account for each role.
Areas covered
- Login, password reset and session handling.
- Access control: whether one user can see or change another user’s records, or reach an administrator’s functions.
- Input handling, including injection and cross-site scripting.
- Business logic: prices, limits, approvals and workflows that can be bent out of order.
- File upload and download.
What is not covered
Denial-of-service and load testing are out of scope, and so is anything outside the agreed written rules. Mobile apps are covered by application security testing, and a line-by-line code review by our source code review service.
How we test
Testers follow OWASP WSTG for the tests and OWASP ASVS for the verification requirements, with PTES and NIST SP 800-115 for the overall process and CVSS for severity. The method is named in the scope and again in the report.
We test both as an outsider and as a logged-in user. The outside view shows what anyone on the internet can reach. The logged-in view shows what a customer, a partner or a member of staff could do beyond their rights, which is where access control flaws appear.
Testing live services safely
Testing is paced so live systems keep running, and anything that could affect availability is agreed with you first.
What the report contains
Every finding is proven. We confirm each weakness and record the proof. If we cannot show it is real, it is not in the report.
One report serves three readers: a short summary for leadership, full detail for engineers, and control mapping for auditors and regulators. For what auditors usually ask to see, read our guide to penetration testing evidence for audit.
How findings map to your audit
The report names the specific control for each finding. At framework level, the mapping looks like this:
| Framework | How a web application finding is used |
|---|---|
| PCI DSS | Evidence for requirement 11.4 (penetration testing) where the application handles card data |
| ISO/IEC 27001:2022 | Evidence for technical vulnerability management and security testing controls |
| SOC 2 | Evidence for monitoring through separate evaluations |
| OWASP ASVS | The verification requirement each finding fails |
| Your regulator’s rules | Mapped in the same report |
From scoping to retest
- Scoping: a free 90-minute scoping session. An NDA is available before you share any details.
- Proposal: a scoped proposal within 24 hours of the call.
- Testing: paced around your live services.
- Report: report within 10 business days of testing.
- Retest: retest included, so you can show the fixes held.
We work from Jakarta (UTC+7), which shares the working day with Southeast Asia and Hong Kong and most of the day with Australia and North Asia. Meetings and reports are in English.
A web application engagement
Before a major sale, an e-commerce platform asked us to test its checkout, vouchers and payments. Read how we tested the shopping journey in our web application security testing case study.
Which test do you need?
A penetration test proves what can be broken. VAPT adds the breadth of a scan with manual confirmation. A vulnerability assessment lists and ranks known weaknesses. If partners and apps call your systems directly, add API penetration testing. Application security testing is the wider program that builds testing into each release, and FOCTOS adds automated testing for web apps and APIs with people reviewing the results.
Questions about web application testing
What is the difference between a web application test and an API test? A web application test works through the screens your customers and staff use. An API test goes straight to the interfaces behind them. If partners or mobile apps call your systems directly, test the APIs as well.
Will testing disrupt our live system? We plan so it does not. Rules agreed in writing set what we test, when and how, and senior testers control the pace.
Do you test with logged-in users? Yes, when you provide test accounts. Testing each role shows whether one user can reach another user’s data or an administrator’s functions.
How long does it take? Usually 5 to 10 working days of testing. Larger scopes take longer; we agree the timeline first.
Can the report be used for our audit? Yes. Findings are mapped to ISO/IEC 27001:2022, SOC 2, PCI DSS and your regulator’s rules.
Start with a scoping session
Book a free scoping session to agree what to test, or request a scoped proposal if you already know your scope. See also how we work with SaaS and technology companies, retail and e-commerce and penetration testing for banks.