Web Application Penetration Testing

A web application penetration test is a manual security assessment of a web application and the APIs behind it, performed from an attacker's perspective. Our testers log in with the roles you provide, map every function and endpoint, and then try to break authentication, authorisation, input handling, session management and business logic. The difference from a scanner: we find the flaws only a human sees, such as a user who opens another customer's invoice by changing an ID, or a checkout that grants a discount for a negative quantity.

The OWASP Web Security Testing Guide (WSTG) and the OWASP Application Security Verification Standard (ASVS) for coverage, the OWASP Top 10 as the minimum bar, and the Penetration Testing Execution Standard (PTES) and NIST SP 800-115 for process. The report states the methodology, so your auditor or customer never has to ask whether a recognised approach was used.

For most web applications we recommend grey box: you provide test accounts per role and documentation, we test as a registered user or customer would. That yields the most findings per testing day, because the time goes into testing rather than guessing URLs. Black box simulates an anonymous attacker and is a useful addition; white box (source code access) is added for critical applications or when a framework such as PCI DSS asks for code review.

Yes. Modern web applications are a frontend plus one or more APIs (REST, GraphQL, gRPC), and most critical flaws live in the API layer: missing object-level authorisation, mass assignment, rate limiting, insecure token handling. We test the API directly, independent of the frontend, and include third-party integrations and webhooks where they are in scope.

An application of average size with two or three roles typically needs three to eight testing days, with the report delivered within a week of the last testing day. Larger platforms with many roles, workflows and APIs need more. During scoping we fix the day count and put it in writing, including the retest.

Either. A representative acceptance environment is ideal for tests that may modify data; production gives the truest picture of configuration, WAF and monitoring. Many clients choose acceptance with a short verification on production. We agree in advance which tests run where, which are excluded, and how we escalate critical findings the same day.

Every test is quoted on scope; there is no fixed price list. The drivers are the number of applications and roles, the size of the API, the depth required (grey or white box), reporting requirements and whether a retest is included. After a 20 to 30 minute scoping call you receive a written proposal within a few working days with the day count and the named lead tester. Our cost guide explains the maths.