Web Application Penetration Testing

The Top 10 is a category list, not a test plan, so the work here follows the OWASP Web Security Testing Guide, and the findings that matter most usually sit in access control and business logic. Access control we test by holding two or more live sessions at once and replaying one role's requests as another, walking object identifiers, and checking whether the server enforces the restriction the interface merely hides. Business logic we test by first learning what your application is for. A discount that stacks, a checkout resumed out of order, a workflow approved by the person who raised it, a quantity field that accepts a negative number: none of those are injection flaws, and a scanner has no notion that they are wrong. That is why this engagement is manual and exploit-driven, with tooling used to widen coverage rather than to replace judgement.

Four things: the target URLs, the environment they sit in, a working test account for each role you want covered, and a named contact we can reach while testing runs. Roles are the item that most often delays a start, because an access-control test needs at least two accounts at different privilege levels, and ideally two at the same level so we can attempt to reach one user's data from the other. If your application has an approval chain, a tenant boundary or an admin console, we need accounts on both sides of it. Beyond provisioning those, the demand on your team is light: a scoping call of roughly thirty to forty-five minutes, a short walkthrough of anything unusual in the application, and someone reachable if a critical finding lands mid-test. What is agreed in scoping is written into the Rules of Engagement before testing begins.

We prefer staging, provided it mirrors production in code, configuration and roles. A staging environment that lags a release, runs debug settings or holds a much thinner dataset produces findings you cannot act on and hides ones you needed. Tell us what differs and we will say whether it still represents the live application. When production is the only realistic target, which is common where integrations cannot be reproduced elsewhere, testing runs in agreed windows, destructive actions stay off the table, and we keep a line open to your team throughout. In practice that means avoiding mass data creation, not exercising payment or notification paths that reach your real customers, and agreeing in advance which accounts and records are ours to touch. Those boundaries go into the Rules of Engagement, so both sides work from the same written document rather than an understanding.

A single web application usually runs one to two weeks of testing, with a retest window afterwards once your fixes are in. Three things move it. Roles: each additional privilege level enlarges the access-control matrix we have to walk, because a four-role application means many more pairings to check than a two-role one. Features: a workflow carrying state, money or approvals takes longer than a static surface of the same page count. Endpoints: breadth costs time, though usually less than depth does. What drives it least is raw page count, which is why a sitemap alone tells us little at scoping. We confirm the timeline in writing once scoping is done, alongside the scope and a fixed price. You also do not wait for the report to hear bad news, since a critical finding reaches you within three hours of discovery.

The retest is part of the engagement rather than a separate invoice, and the pair of documents is what an auditor actually cares about. The findings report carries a proof of concept for each issue, so a reviewer can see the flaw was reproduced by hand rather than inferred from a scanner signature, alongside an executive summary, remediation guidance and a rating of business impact. The verified retest report is the other half: after you remediate, we test each finding again and record whether it is genuinely closed, and a fix that does not hold leaves the finding open with the reason stated. That gives your auditor a trail from discovery to confirmed closure instead of a list marked resolved by assertion. An attestation letter is included for questionnaires that ask for one, and findings are graded against the published standards named on this page.