The OWASP Testing Guide does not read like a document that stayed still. Published as version four in 2014, it has since been renamed, restructured, moved to a new publishing platform, and expanded to cover technology that barely existed when the 2014 edition went out. What follows describes both the 2014 document and the thing it became, because in this case the two are inseparable: the guide’s current form is the direct, actively maintained successor of the 2014 text, not a different project that happened to inherit its name.
A wiki becomes a GitHub project
OWASP, the Open Web Application Security Project Foundation, is a nonprofit that produces open-source security resources for developers and security professionals, largely through volunteer contribution. The Testing Guide sits among its flagship projects, the small set of OWASP documents that receive the highest level of ongoing maintenance. Version four, in 2014, marked a structural change as much as a content update: the guide moved off a wiki-based publishing system and onto GitHub, turning it into a versioned, collaboratively edited document rather than a page anyone could quietly edit at any time.
That platform shift is why the guide’s version history reads more like software than like a book. After v4 came v4.1, then v4.2 in December 2020, the current stable release, with a v5.0 already under active development. As of this research, the project’s current live page credits Rick Mitchell and Elie Saad as project leaders, with contributions from 183 people and nearly ten thousand stars on its GitHub repository, numbers that put it among the more actively maintained security-documentation projects on the platform, not a document someone wrote once and walked away from.
Six sections make up the guide beyond the testing methodology itself: a foreword, an “about” page, an introduction explaining scope and how to use the document, the OWASP Testing Framework describing how security testing fits across a software development lifecycle, a reporting section standardizing how findings should be written up and named, and a set of appendices covering testing history, tools, further reading, fuzzing, and encoded injection techniques. The reporting section matters more than it might sound: a shared naming convention for findings is what lets one security team’s report reference “WSTG-INFO-02” and have another team, anywhere in the world, know exactly which test that refers to without re-reading the whole methodology.
Thirteen categories, in the order an assessment actually runs
The guide’s methodology follows something close to the order a real security assessment tends to take. It begins with information gathering: working out what a target application exposes before touching anything sensitive. From there it moves through configuration and deployment management testing, identity management testing, authentication testing, authorization testing, and session management testing, the layers that decide who gets in and what they can do once they are inside.
| Stage | What it checks |
|---|---|
| Information Gathering | What the application exposes before testing begins |
| Configuration & Deployment Management | Server and deployment hygiene |
| Identity Management | How accounts and roles are created and managed |
| Authentication | Login and credential handling |
| Authorization | What an authenticated user is allowed to do |
| Session Management | How logged-in state is tracked and protected |
| Injection | Whether user input can alter application behavior |
| Error Handling | What information failures leak |
| Weak Cryptography | How data is encrypted, and how well |
| Business Logic | Whether the application’s own rules can be gamed |
| Client-Side Testing | Browser-side vulnerabilities |
| API Testing | Security of application programming interfaces |
| WebAssembly Testing | Security of WebAssembly-based application code |
The last two rows on that list did not exist in any meaningful form in the original 2014 edition. API testing and WebAssembly testing were folded in as the way web applications get built changed, a reminder that a “testing guide” is only useful if it tracks how software is actually shipped, not how it was shipped a decade earlier.
What v5.0 is adding
At the time of this research, version five of the guide was already in development on OWASP’s GitHub repository, reaching into territory that did not exist as a mainstream security concern in 2014: WebSocket security, OAuth 2.0 and PKCE authentication flows, and testing for serverless applications, where there is no persistent server to probe in the traditional sense.
Each of those additions maps to a real shift in how web applications get built and deployed. WebSockets keep a connection open instead of the old request-and-response pattern, which changes what an attacker can do with a single foothold. OAuth 2.0 and PKCE cover the login flow most consumer apps now use to let a user sign in with an existing account rather than a fresh password. Serverless applications remove the always-on server a tester would normally probe directly, replacing it with short-lived functions that only exist while handling a single request. None of the 2014 guide’s thirteen categories were built with any of that in mind, which is exactly why a v5.0 was needed rather than a patch to v4.2.
Where the 2014 text went
If you are specifically hunting for the original 2014 version four release, it is worth knowing it is not separately hosted anymore. OWASP’s current project page lists only the newer v4.1 and v4.2 releases, not the original v4 text as its own artifact. That is a reasonable outcome for a living, versioned document, but it does mean the exact 2014 wording is harder to pin down today than the guide’s current, actively maintained form at wstg.owasp.org. Anyone building security-testing practice on this guide today should be working from the current WSTG, not treating a decade-old PDF as current methodology.