OWASP WSTG: the testing guide for web applications

WSTG contains twelve thematic areas that together cover the life cycle of a web application test, from gathering information to missing checks on the client. Each area groups individual tests, and every test describes its goal, the procedure, and what a positive finding looks like.

• Information gathering: what the application, its errors, and public sources give away about it.
• Configuration and deployment: the environment, headers, files left behind, administrative interfaces.
• Identity management: creating accounts, roles, and the boundaries between them.
• Authentication: login, the second factor, password recovery, blocking repeated attempts.
• Authorization: access to other users’ objects and to functions beyond the role.
• Session management: validity, renewal, and termination of a session, behavior on logout.
• Input validation: injections of every kind, including scripting on the browser side.
• Error handling: what the application gives away when something goes wrong.
• Cryptography: encryption in transit and at rest, and the algorithms used.
• Business logic: the order of steps, limits, race conditions, and abuse of a legitimate feature.
• Client side: what runs in the browser and can be changed there.
• API: the interface, its authorization, and older versions nobody switched off.

A test label is read from the left: the prefix WSTG, the abbreviation of the thematic area, and the sequence number of the test inside it. The identifier WSTG-ATHZ-04 therefore marks the fourth test in Authorization Testing, specifically the check for insecure direct object references. Identifiers are stable across versions of the guide, so they can still be referenced years later.

The practical benefit shows up in the report and in the contract. The sentence “authorization was tested” can’t be checked, whereas a list of identifiers says exactly which procedures were carried out. A client can tell whether a second proposal covers the same ground, and on a repeat test the scope can be compared year against year.

The scope comes from picking the areas and tests that make sense for a specific application. The guide is a catalog, not a mandatory list: it contains procedures for technologies your application may not use at all. A whole area can therefore fall away without lowering the quality of the test.

The areas that raise the scope most are the ones that depend on the number of roles, because authorization is tested for every combination of role and object type. That is why an application with three roles is estimated differently from one with a single role. How we test applications and APIs under the guide is described on the service page.

WSTG concerns web applications and their interfaces, not everything else. It doesn’t cover testing of infrastructure and networks, it doesn’t cover the course of an engagement, and it doesn’t decide how severe a finding is. Those three things are covered by other documents, and it is worth knowing that before the guide gets written into a contract. The closest neighbor is the survey of risks, and how the guide differs from the Top 10 ranking has its own comparison.

• The course of an engagement from the agreement on scope to the report is described by the PTES standard, not by WSTG.
• The severity of a finding is expressed on a separate scale, usually with a CVSS score.
• The requirements an application is verified against come from the ASVS catalog. WSTG says how to test, ASVS says what should hold.

A companion to the guide is a set of practical OWASP notes on individual topics, the cheat sheets. They aim at developers rather than testers and come in handy once a test produces a finding and the question is how to fix it properly.

The stable version is 4.2. The guide keeps evolving in an open repository, though, so the development version tends to run ahead of the one marked stable. For the brief of a test it therefore pays to state the version number the work follows.