OWASP Web Security Testing Guide: plan a web app pentest

The OWASP Web Security Testing Guide is the free, open reference that security testers use to check a web application, and it doubles as a ready-made plan for a pentest. This post shows how to use it: start by mapping the app, pick the test categories that match what your app does, run them in a fixed order, and ask for a report your team can act on.

If you would rather have someone run that plan for you, whitehatstoic tests web apps and AI systems for weak spots and hands you a written report with fixes, then retests once you have fixed them.

What the OWASP Web Security Testing Guide is

The Web Security Testing Guide (WSTG) is an OWASP flagship project. The current stable release is version 4.2, published on the web at wstg.owasp.org and as a PDF, and version 5.0 is in development.

The guide defines its terms plainly. A security test methodically checks whether the app's security controls work. A vulnerability is a flaw in design, implementation, operation or management that could be used to break the system's security goals. A threat is anything, from an outside attacker to an internal user, that could harm the app's data by using a vulnerability.

Its method is black box: the tester starts knowing little or nothing about the app. Testing then splits in two. Passive testing means exploring the app as a user to learn how it works. Active testing means running the guide's tests, category by category.

The guide is also honest about its limits. Its foreword says security testing is not a good stand-alone measure of how secure an app is, because there are endless ways to break an app and no test can try them all. Treat it as a plan that makes testing consistent and repeatable, not as proof of safety.

Start passive: map every entry point

Every active test needs a target, so the plan starts with information gathering. The WSTG test for this, Identify Application Entry Points (WSTG-INFO-06), asks the tester to walk through the app and note every request it makes.

The guide's own advice is to use an intercepting proxy together with a spreadsheet. The proxy records every request and response. The spreadsheet lists, for each page, the parameters, custom headers and form fields it sends, and whether it uses GET, POST or other methods.

Pay special attention to hidden form fields. The guide warns that they often carry state, quantities or prices that the developer never meant anyone to see or change. Each one you find is a place to test later.

By the end of this step you should know every access point of the app: headers, parameters, cookies, APIs and the technology behind them. A team can do much of this before the tester arrives, which saves paid testing time.

The 12 test categories and their IDs

Active testing in WSTG v4.2 is split into 12 categories. Each test has an ID, such as WSTG-ATHZ-04 for insecure direct object references, so a plan, a finding and a retest can all point at the same test.

The 12 categories of WSTG v4.2, summarized from wstg.owasp.org.

The categories run from the outside in: information gathering, configuration and deployment, identity management, authentication, authorization, session management, input validation, error handling, cryptography, business logic, client-side testing, and API testing. Input validation is the largest, with tests for cross-site scripting, SQL injection, command injection, template injection and server-side request forgery.

Pick the categories your app needs

Not every test applies to every app. Read the category list against what your app actually does and mark each one in, out or partial. A few questions do most of the work:

• Do users sign in? Then identity management, authentication, session management and authorization are all in. These usually hold the findings that matter most.
• Do users see each other's data? Authorization testing, especially privilege escalation and insecure direct object references, deserves the most time.
• Does money or a limited resource change hands? Business logic testing covers forged requests, process timing, limits on how often a function can be used and bypassed workflows. Scanners rarely find these.
• Can users upload files? Two business logic tests cover unexpected file types and malicious files.
• Is there a GraphQL API? API testing in v4.2 has one test, for GraphQL. A REST API is still tested through the input validation, authorization and session categories.

Write the limits down too. The guide's reporting chapter names the usual ones: areas out of bounds, broken functionality, lack of cooperation, lack of time and lack of access or credentials. Our penetration test preparation checklist covers the access and accounts a tester needs before day one.

A worked example: five days on a small SaaS app

Say your team runs a project management app. Users sign up, invite teammates into a workspace, upload attachments and pay for seats. There is a REST API and no GraphQL. Here is one way to turn the OWASP Web Security Testing Guide into a five-day plan.

1. Day 1, map. Run the information gathering tests. Walk every screen through a proxy as an owner, an admin and a plain member, and fill the entry point spreadsheet. Note every hidden field and every ID in a URL.
2. Day 2, configuration and identity. Check HTTP methods, old and backup files, admin interfaces and any cloud storage the app uses. Test sign-up, invitations and account enumeration.
3. Day 3, sign-in and sessions. Test lockout, password reset, remember-me and default credentials. Then cookie attributes, session fixation, cross-site request forgery, logout and timeout.
4. Day 4, authorization and logic. Using two workspaces, try to read and change the other workspace's projects and attachments by changing IDs. Try to add seats without paying and to skip steps in the invite flow. Upload unexpected file types.
5. Day 5, input, client side and wrap-up. Test the entry points from day 1 for injection and cross-site scripting, check CORS and browser storage, then write up the findings.

Every finding gets its WSTG ID. When the fixes land, the retest runs the same IDs again, so nobody argues about what was checked. For the authorization day, our guide to authorization testing automation shows how to keep those checks running after the pentest ends.

What the report should hold

The guide says the technical work is only half the job, and that testing quality does not matter if the client cannot understand the findings. Its reporting chapter suggests a structure, offered as suggestions rather than strict rules:

• Introduction: version history, the team, the agreed scope, the limitations, the timeline and a disclaimer that the test is a point-in-time assessment.
• Executive summary: why the test was done, the key findings in business terms and strategic recommendations, without jargon.
• Findings: a summary table with each finding's risk level, then details for each: an ID, a title, likelihood, impact, risk, how to reproduce it, how to fix it, and references.
• Appendices: the method, how risk levels were set, cleaned tool output, and a checklist of the tests run.

The guide also says to mask sensitive data such as passwords and personal details in the report, and to encrypt the report so only the receiving team can read it. If the work is a retest, it suggests a section showing the status of each earlier finding. When you plan the test, agree on this format up front. If you also want a standard to measure the app against, pair the guide with OWASP ASVS as a test plan.

Frequently asked questions

Is the OWASP Web Security Testing Guide free?

Yes. OWASP publishes it openly on the web and as a PDF, and its contents are licensed under Creative Commons.

Which version of the WSTG should I use?

Version 4.2 is the current stable release. Version 5.0 is in development, and its draft content can be read on the project's latest pages.

Does following the WSTG mean the app is secure?

No. The guide itself says no test can try every way an app might break. It gives you a consistent, repeatable plan, and a report records what was tested at one point in time.

How is the WSTG different from OWASP ASVS?

ASVS lists the security requirements an app should meet. The WSTG explains how to test a running web app for weaknesses. Many teams use ASVS for what to check and the WSTG for how.

Get started

The OWASP Web Security Testing Guide gives you the plan; running it well takes time and practice. whitehatstoic tests web apps, APIs and AI systems and delivers a written report with fixes and a retest after you have fixed them. Every engagement is scoped after a short call.

Building something that has to be safe? Book a meeting with whitehatstoic: tell us the product, the deadline and your biggest worry, and we reply with a plan.