The Web Security Testing Guide describes a person testing, which decides what automates
ASVS tells you what must be true. CWE tells you what the mistake is called. WSTG tells you how to go and find out, which makes it the most practical of the three and the hardest to automate honestly. It is written for a tester with a browser, a proxy and patience, and a large part of it is judgement wearing the clothes of a procedure. Below is which of its categories this platform actually executes, and which ones it leaves where they belong.
Which layer executes which category
WSTG categories are groups of tests rather than single requirements, so a control maps to a category by executing tests within it rather than by covering it. Nothing here claims a category is complete, and a category nothing reached is uncovered.
Runtime validation
E4The closest thing here to what the guide describes, because WSTG is written for somebody testing a running application. Authorisation testing is performed with two accounts. Input validation testing sends type-violating and oversized payloads to the endpoints the application advertises. Error handling testing forces failures and reads what came back. Each is a test executed against the deployment rather than an inference about it.
Repository validation
E2The layer WSTG does not describe, which is why it is worth having beside the others. The guide assumes a tester with a browser and no source. Reading the source finds credential material that configuration testing would only find if it happened to be exposed, and it finds the absent authorisation check behind an endpoint that answers correctly for the account you happen to be holding.
Public URL scan
E4Covers the parts of configuration and cryptography testing that are visible from outside: what the deployment enforces about transport, and what its response headers say. It is the cheapest of the three and the narrowest, and every category it cannot reach stays uncovered.
Every WSTG category the pack reaches
Eight of the thirteen controls execute tests inside a WSTG category, across six of the twelve categories. Each row names the category, how the result is established, and what passing requires. Executing tests inside a category is not covering the category, and the six untouched ones are named below.
Four things worth knowing before quoting WSTG
This guide is widely cited and rarely read closely. The misreadings all point the same way, which is towards claiming more than a run can support.
It is a methodology, not a standard to pass
There is no conformance, no level and no certificate, because WSTG describes how to test rather than what must hold. A product cannot be WSTG compliant. What it can have is a record of which tests were executed against it and what they returned, which is a more useful artefact anyway and one nobody can award you.
A category is a group of tests, so covering one is a strong claim
Authentication testing alone contains tests for credentials over an encrypted channel, default credentials, weak lockout, bypassable schemas, remember-me behaviour, password reset and more. Executing the lockout test is executing one test in that category. Reporting it as authentication testing covered would be the exact overstatement this page exists to avoid.
Half the guide is judgement and should stay with a person
Business logic testing asks whether a sequence a real user can perform produces a state your business did not intend. Client side testing asks what happens in a browser you do not control. Identity and session management ask whether the model is right, not whether a header is present. Those are the categories where a tester earns their fee, and nothing automated should be reported against them.
The six categories nothing here reaches
Information gathering, identity management testing, session management testing, business logic testing, client side testing and API testing have no control behind them in this pack. Information gathering is reconnaissance rather than a pass or fail. The other five need either a human tester or knowledge of your application that a validation is not given. They are reported uncovered rather than folded into a number.
What the result looks like
An illustrative extract, not a real customer result. Every row carries the evidence grade behind it, and a control nobody could establish says so.
| Control | Status | Evidence | Note |
|---|---|---|---|
| Transport security (TLS) is enforced | Verified | E4 | WSTG-CRYP, plain HTTP redirected and no deprecated protocol accepted |
| Error responses do not leak internals | Failed | E4 | WSTG-ERRH, a forced failure returned a stack trace naming the framework |
| Object ownership is enforced server-side | Verified | E4 | WSTG-ATHZ, a second account's request for the record was refused |
| Secrets are managed outside source code | Verified | E3 | WSTG-CONF, no credential material in the tree or the history |
| Health checks and basic observability | Uncovered | Not graded | The pack maps no WSTG category to it: the guide tests an application, not its operations |
Mapped to published standards
Each control is tested against a named clause, so a result means something outside our own vocabulary. Mapping is not certification, and none of these bodies endorse StackAttest.
What this does not tell you
- It is not a penetration test. A deterministic check and a runtime probe are not an adversarial human engagement, and there are classes of weakness only a person hunting for them will find.
- It is not SOC 2 and does not replace it. SOC 2 attests to organisational controls over time; this validates technical controls in the software. They answer different questions for different buyers.
- It does not replace human due diligence. It gives a reviewer repeatable evidence to start from, which is a different thing from being the reviewer.
- Controls the run could not reach are reported as uncovered rather than passed. A result you did not earn is worse than no result.
- It is not a certification and there is no such thing to award. OWASP publishes the guide openly, and neither OWASP nor the WSTG project endorses, accredits, reviews or has any relationship with StackAttest.
- It does not cover any category. Eight controls execute tests inside six of the twelve categories, and a category contains many more tests than the ones executed. Executing a test is not covering the group it belongs to.
- Six categories are untouched, including business logic and client side testing. Those are where a human tester finds what a procedure does not, and reporting anything against them here would be inventing a result.
- It is not a penetration test and WSTG is largely a penetration testing methodology. Running some of its tests automatically is useful precisely because it clears the ground; it does not do the job the guide was written for.
Questions
Can an application be WSTG compliant?
No. WSTG is a methodology describing how to test rather than a set of requirements to satisfy, so there is nothing to comply with and nobody who could certify it. What is meaningful is a record of which of its tests were run against your application and what they found.
Which WSTG categories can be automated?
The ones whose answer comes from observing the system rather than reasoning about it: parts of configuration testing, cryptography testing, error handling, input validation, and the direct object reference tests in authorisation. The ones that resist automation are business logic, client side, identity and session management, because each asks whether a design is right.
How does WSTG relate to ASVS?
They are two halves of the same project's thinking. ASVS states the requirement, WSTG describes how you would go and test it. If you are deciding what must be true, read ASVS. If you are holding an application and want to know what to try, read WSTG.
Is running some WSTG tests automatically worth anything?
Yes, for a specific reason: these are the tests that regress quietly. A header dropped in a config change, a redirect lost behind a new edge rule, an error handler that stopped redacting. A person runs the guide once and finds more than any machine. A machine reruns the narrow part on every deploy, which is the only way that part stays true.
Related
Find out what is actually true of your application
Start with the layer you can run today. The report says which layers ran and what they could not reach, so the result is honest about its own limits.