OWASP Top 10 and WSTG: how the two differ

Both documents come from OWASP, but each answers a different question. Top 10 answers “what should worry us,” WSTG answers “how do we verify it.”

OWASP Top 10 is a survey of ten categories of web application risk, put together from data on how often weaknesses occur in real applications and supplemented by a survey among specialists. It comes out in editions labeled by year and serves mainly for awareness and for unifying the vocabulary between security and development.

Its strength is that it can be read in an hour and that a non-technical reader understands it. Its limit is that same brevity: ten items can’t cover everything that gets exploited in applications, and they deliberately don’t try. A detailed breakdown of the categories has its own entry on the structure and editions of Top 10.

OWASP WSTG, in full the Web Security Testing Guide, is a testing guide. For each area it describes what is tested, by what procedure, what the expected result is, and what a finding looks like. The stable version is 4.2 and the individual tests carry their own labels, which can be referenced in a report.

The guide doesn’t decide what counts as severe, and it doesn’t prescribe what has to be tested. It is a catalog of procedures the tester picks from according to the scope of the engagement and the type of application. How test labels are read and what the twelve areas contain is covered in the entry on the contents and labeling of WSTG.

A test limited to Top 10 leaves out whole areas that the survey of risks doesn’t include, because they didn’t fit into ten items. These are not marginal things: business logic is missing, so is session handling across roles, the behavior of the application at the edge of its limits, and most of what gets tested on the client side.

• Business logic flaws: an order can be completed with a changed price, a discount can be applied repeatedly, an approval step can be skipped.
• Race conditions: two requests sent at the same moment both go through, although only one was supposed to.
• Tests specific to APIs: a missing check at the level of the individual object, interface versioning, forgotten older endpoints.
• Behavior on error: in reaction to unexpected input the application reveals its internal structure or ends up in a permissive state.
• Client side: manipulating data in the browser, storing sensitive information outside the session, bypassing checks made only in the interface.

The second problem is measurability. A brief that says “against Top 10” has no way of proving fulfillment, because it defines neither the number nor the depth of the steps. A brief that refers to specific areas of the guide can be verified, because every test in it has its own identifier.

Full scope under WSTG means going through all twelve areas and picking, in each of them, the tests that fit the application. It never means mechanically ticking off every test: the guide also contains procedures for technologies your application doesn’t use at all.

The difference from a check against Top 10 is that for each area you can document what was done and with what result. The report is then not a list of findings without context but a map of coverage. What a test in full scope under the guide looks like is described on the service page.

Top 10 works as a framework for a check in three situations: an internal tool with no sensitive data and no access from the internet, a first quick check at a startup that needs to know whether it has a fundamental hole, and an introductory training for a development team that is only starting with security.

Choose Top 10 if you need a quick picture and are deciding whether a full test is worth the money at all. Choose the procedure under the guide if the application processes personal or payment data, if it is reachable from the internet, or if you need to show the deliverable to an auditor or a customer.