What is web application penetration testing?
Web application penetration testing is an authorized attempt to misuse a web application the way a patient attacker would, inside a written scope. The result is a short list of issues we can prove, ranked by what they let someone do, with steps a developer can follow and a retest after you fix them. It is not a certificate, and it is not a scanner subscription with a logo on the cover.
What we test
We test the roles you provision. A finding that only exists for an anonymous visitor is a different problem from one that lets one customer read another customer’s data, and the report keeps that difference visible. Authentication, session handling, access control, injection, server-side request forgery, file handling, and business logic are the usual ground. We follow the APIs the application already calls, including the ones a browser user never sees named in a menu. If the API is a product of its own, the closer fit is an API penetration test.
Coverage is organized against the OWASP Web Security Testing Guide, and where you want a requirements view we read the design against the OWASP Application Security Verification Standard. The OWASP Top 10 is a useful index. It is not the whole test. Business rules that only your application has — a refund that can be replayed, a limit that resets, a step that can be skipped — are in scope when the flow is.
You provide a stable environment, accounts for each role in scope, and a window when we are allowed to work. Production testing is possible when you accept the constraints and we agree the safeguards in writing. We do not need your production database, and we will not take a copy of customer data to make a point.
Approach and standards
Most engagements are grey-box. You give us accounts and a description of what the application is for. We do not get a running commentary on every control, and we do not pretend that ignorance of the design is a virtue when an account would make the test honest. Black-box, with no accounts, is the right shape only when the question is what an outsider can do before signing in. White-box, with source, is available when you want the finding traced to the change that should fix it.
The method is the one on our testing methodology page: written scope, rules of engagement, testing inside that scope, a report, and a retest. Denial of service stays out unless the rules allow it. If a vulnerability would expose personal data, we capture the minimum evidence required to prove it and stop.
Teams preparing for a customer review sometimes want the findings mapped to ISO 27001, SOC 2, or PCI DSS. We will map gaps to a control set you name. That mapping is not an audit opinion, and it does not certify the application. A vulnerability assessment is the better first purchase when you need coverage across many assets rather than depth on one application.
How long it takes and what affects the price
A focused application is often five to ten testing days after the rules are signed, plus a few days to write the report. The retest is a shorter window once the fixes are ready. The contract names the dates. These ranges are the usual shape, not a price list.
The price moves with the number of roles, the number of distinct applications or hostnames, whether the API surface is large, whether the environment is production, and whether source review is included. A single customer-facing application with two roles is a different engagement from a suite of internal tools that share a login. We will say so during scoping rather than stretch one quote across both.
What you receive
You receive the rules of engagement you signed, a technical report, a short summary for leadership, and a retest note. Each finding says where it is, what it allows, how it was confirmed, and what to change. Evidence is the minimum required to reproduce the issue. We do not attach piles of personal data to prove that personal data was reachable. There is no sample report dressed up as a client deliverable. The methodology page describes the documents. None of them is a certificate.
When to choose this
Choose this when the question is what a signed-in user, or an outsider, can do to one web application. Choose an API penetration test when the interface is the product and the browser is incidental. Choose a cloud security assessment when the worry is the account the application runs in, not the requests it serves. Choose network penetration testing when the question is which hosts and management paths are reachable. If you are not sure, say so on the contact page. A shorter conversation is enough to tell which one is the first engagement.