Web application penetration testing

A web application test looks at the application itself, not just the server it runs on. The tester uses the application the way a real user would, then checks whether it can be made to do things it should not. The areas a thorough test covers include:

• Sign-in and accounts: registration, login, password reset and multi-factor authentication.
• Permissions: whether one user can see or change another user’s data, or reach admin functions.
• Sessions: how the application keeps users signed in and signs them out.
• Input handling: how the application treats data it receives from users and other systems.
• Business logic: whether the application’s own rules (prices, approvals, limits) can be bypassed.
• Configuration: error messages, encryption in transit and the security settings of the web server.

These match the test areas in the open OWASP Web Security Testing Guide, which OWASP says should be tailored to each application rather than run as a fixed list.

• Before launching a new application, or a major release that changes sign-in, payments or permissions.
• When a customer’s security questionnaire or contract asks for a recent independent test.
• When a standard asks for one: card-payment applications fall under PCI DSS testing, and an ISO 27001 or SOC 2 programme often uses one as evidence.
• On a regular cycle for applications that hold personal or financial data.

The NCSC’s secure development guidance treats a point-in-time test as one part of a wider approach, alongside automated testing built into your development pipeline. A penetration test is most useful when it checks the things automated tools cannot, such as permissions and business logic.

Firms price the scope you give them, so the more precisely you describe the application, the more comparable the quotes. Tell every firm:

• The application’s address and what it does, in a sentence.
• The user roles to test (for example customer, staff and administrator), and that you will provide an account for each.
• Any APIs the application relies on, and whether they are in scope. A separate API test may suit large APIs.
• Which environment is to be tested, the testing window, and who to call if something goes wrong.
• Anything out of scope, such as third-party payment pages or services you do not own.
• What you need in the report, and whether a retest of fixed issues is included.

The free scoping template has a web application section you can fill in and send to each firm.

Ask each firm which methodology it follows. As well as the testing guide, OWASP publishes the Application Security Verification Standard, a set of security requirements with levels of assurance that OWASP suggests can also be used in procurement. If your application has a security requirement to meet, naming the ASVS level in your request gives every firm the same target.

The report should explain each finding in plain terms, show evidence your developers can reproduce, rate it by risk and say how to fix it. CREST’s guidance on defensible penetration tests sets out the same expectations for how a test is scoped, delivered and signed off. See what a good report contains.