Anyone can list the sections of the OWASP Web Security Testing Guide. Fewer people can explain what a tester actually does inside each one, what a realistic finding looks like and how the categories connect. That gap matters, because the value of the guide lies in the connections. A leaked file path found during information gathering becomes the clue that makes an injection attack possible. A weak password reset flow found during authentication testing opens the door to the access control problems you test later.
This article goes through the core OWASP WSTG testing categories one by one. For each, you will find what the category covers, the questions a tester asks, the kinds of issues that turn up in real applications and the practical fixes development teams should apply. It is aimed at testers who already understand the basics and want a more detailed mental model. If you are new, the overview of the OWASP Testing Guide is a gentler starting point.A note on versions: the guide is community maintained and category names and numbering can change between releases. The structure below follows the widely used 4.2 layout. Confirm the current release on the official OWASP site and record the version you tested against.
Information Gathering (WSTGINFO)
Information gathering is the reconnaissance phase. The goal is to build an accurate picture of the application before attempting anything intrusive. Done well, it makes every later phase faster and more precise.
What testers examine
Search engine discovery, to find indexed pages, leaked documents or forgotten subdomains
Web server and framework fingerprinting through headers, error pages and file behaviour
Metadata files such as robots.txt, sitemap.xml and security.txt
Application entry points: every parameter, cookie, header and form field that accepts input
Execution paths through the application, including workflows and rolebased branches
The application architecture, including load balancers, content delivery networks and third party services
Typical findings
Version numbers disclosed in headers, administrative paths listed in robots.txt, staging environments reachable from the internet and comments in clientside code that reveal internal hostnames. None of these is catastrophic alone. Together, they hand an attacker a head start.
Remediation
Remove unnecessary version banners, keep sensitive paths out of public metadata, restrict nonproduction environments and strip internal comments from production builds. Remember that robots.txt is a request to crawlers, not an access control.
Configuration and Deployment Management Testing (WSTGCONF)
A secure application can still be deployed insecurely. This category looks at the environment around the code: servers, platforms, file handling and administrative surfaces.
What testers examine
Network and infrastructure configuration, including unnecessary open services
Platform configuration, such as default accounts, sample files and enabled debug modes
File extension handling and old, backup or unreferenced files left in web directories
Administrative interfaces exposed to the wrong audience
HTTP methods supported, including unnecessary use of PUT, DELETE or TRACE
HTTP Strict Transport Security and crossdomain policy files
Subdomain takeover possibilities, where a DNS record points to a service nobody controls any longer
Cloud storage permissions
Typical findings
Backup archives such as app.zip.bak downloadable from the web root, administrative consoles accessible from the public internet, dangling DNS records that allow subdomain takeover and misconfigured cloud storage that exposes internal files.
Remediation
Maintain a hardened baseline configuration, automate deployments so that configuration is consistent, remove unused files and services, restrict administrative access by network and identity and review DNS and storage permissions regularly.Review the underlying code too; the source code review lab is useful for spotting unsafe patterns before they reach production.
Identity Management Testing (WSTGIDNT)
Identity management covers how accounts and roles are defined, created and administered. It is easy to overlook, yet weaknesses here underpin many later problems.
What testers examine
Whether role definitions are clear and consistently enforced
Registration: can anyone register, with what validation and can the process be abused?
Account provisioning: who can create accounts and with what privileges?
Account enumeration: does the application reveal whether a username exists through different messages, response times or response sizes?
Weak or predictable username structures
Typical findings
Registration forms that allow privileged roles to be requested through a tampered parameter, login and recovery pages that confirm which email addresses are registered and predictable usernames that simplify credential attacks.
Remediation
Use uniform messages and consistent timing for existing and nonexisting accounts, enforce role assignment on the server rather than trusting client input and apply approval workflows for privileged accounts.
Authentication Testing (WSTGATHN)
Authentication verifies who a user claims to be. Weaknesses here are direct routes into accounts.
What testers examine
Credential transport: are credentials sent over encrypted channels only?
Default credentials on applications and supporting systems
Lockout and rate limiting mechanisms against brute force and credential stuffing
Authentication bypass: can pages be reached without logging in, by forced browsing or parameter manipulation?
Rememberme functionality and how persistent tokens are stored and validated
Browser cache behaviour: can sensitive pages be viewed through the back button after logout?
Password policy strength and password change functionality
Password reset and recovery flows
Multifactor authentication implementation and bypass options
Alternative channels, such as mobile apps or APIs, that may enforce weaker checks
Typical findings
Password reset links that do not expire, reset tokens that are predictable, absent lockout controls, multifactor flows that can be skipped by calling a later step directly and security questions with guessable answers.
Remediation
Use long, random, singleuse, timelimited reset tokens, apply progressive delays or lockout combined with monitoring, require multifactor verification server side at every sensitive step and follow current guidance on password policy that favours length and breach checking over arbitrary complexity rules.
Related reading: applications that rely on signed tokens need extra care and the JWT security best practices guide covers algorithm confusion, weak secrets and unsafe storage.
Authorization Testing (WSTGATHZ)
Authorization decides what an authenticated user may do. Broken access control consistently ranks at or near the top of real world risk lists, so this category deserves generous time.
What testers examine
Directory traversal and local file inclusion, where input influences file paths
Authorization schema bypass, such as reaching administrative functions as a standard user
Privilege escalation, both vertical (user to administrator) and horizontal (user to user)
Insecure direct object references, where changing an identifier exposes another user's data
OAuth weaknesses, including improper redirect validation and scope handling
A worked example
Suppose an invoice endpoint looks like /api/invoices/4821. A tester logs in as user A, captures the request, then repeats it as user B with the same identifier. If user B receives user A's invoice, the server authenticated the request but never checked ownership. That is an insecure direct object reference and it is simple to fix and very common to find. You can practise this scenario in the IDOR and broken access control lab.
Remediation
Enforce authorisation on the server for every request and every object, deny by default, avoid relying on hidden fields or client side checks and centralise access control logic so it cannot be forgotten on a new endpoint.
Session Management Testing (WSTGSESS)
HTTP is stateless, so applications use sessions to remember users. If an attacker can steal, guess or fix a session, they can impersonate the victim.
What testers examine
Session management schema: how tokens are generated, how random they are and how long they last
Cookie attributes: Secure, HttpOnly, SameSite, domain and path scope
Session fixation, where an attacker sets a known session identifier before the victim logs in
Exposed session variables, for instance tokens in URLs or logs
Crosssite request forgery protections
Logout behaviour and whether sessions are invalidated server side
Session timeout, including idle and absolute limits
Session puzzling and session hijacking possibilities
Typical findings
Session identifiers that do not change after login, cookies missing the HttpOnly flag, tokens that remain valid after logout and statechanging requests with no antiforgery protection.
Remediation
Generate long, unpredictable identifiers with a trusted framework, rotate them at login and privilege change, set restrictive cookie attributes, invalidate sessions on the server at logout and apply antiCSRF tokens or SameSite policies to statechanging actions.
Input Validation Testing (WSTGINPV)
This is the largest category and the home of many famous vulnerabilities. The principle is simple: never trust data from the client. The execution is anything but simple, because input travels through many layers and contexts.
What testers examine
Reflected, stored and DOMbased crosssite scripting
SQL injection and other injection forms, including NoSQL and LDAP
Command injection and code injection
Server side template injection
XML related issues, including external entity processing
HTTP parameter pollution and HTTP request smuggling
Server side request forgery
File inclusion and unrestricted upload behaviours
Why context matters
The same input can be harmless in one place and dangerous in another. A string rendered inside an HTML body needs different handling from one placed inside a JavaScript block, an attribute, a URL or a database query. This is why simple blacklists fail and why contextaware encoding and parameterisation are the correct defences.To see how this plays out, work through the SQL injection lab and the crosssite scripting lab. Each shows how an input that looks innocent changes the behaviour of a query or a page.
Error Handling Testing (WSTGERRH)
Error handling is a small category with outsized value to attackers. A well designed application tells users that something went wrong without explaining how it works internally.
What testers examine
Improper error handling that reveals stack traces, file paths, SQL fragments or framework versions
Differences in error responses that confirm or deny hidden conditions, such as whether a record exists
Behaviour when requests are malformed, oversized or unexpected
Typical findingsDetailed stack traces returned on a 500 error, database messages that reveal table or column names and debug pages left enabled in production.RemediationReturn generic user facing messages, log full details server side with appropriate access controls, disable debug output in production and test error paths as carefully as success paths.
Weak Cryptography Testing (WSTGCRYP)
Cryptography protects data in transit and at rest. The usual mistake is not breaking the maths but using it badly.
What testers examine
Weak transport layer security, including outdated protocol versions, weak cipher suites and certificate problems
Padding oracle vulnerabilities, where error differences leak information about encrypted data
Sensitive information sent over unencrypted channels
Use of weak or deprecated algorithms and poor key management
Typical findings
Support for obsolete protocol versions, mixed content that loads over plain HTTP, passwords hashed with fast, unsalted algorithms and secrets embedded in clientside code.
Remediation
Enforce modern TLS versions, enable HSTS, hash passwords with slow, salted functions designed for the purpose, use well reviewed libraries rather than custom cryptography and store keys in dedicated secret management systems.
The Categories Beyond the Core Nine
The guide also covers business logic, clientside and API testing. These are increasingly important:
Business logic testing asks whether workflows can be abused: skipping payment steps, replaying discounts, exceeding limits or manipulating order of operations. Automated tools rarely detect these, so human reasoning is essential.
Client side testing examines DOM manipulation, insecure browser storage, clickjacking, crossorigin resource sharing and similar browserside behaviour.
API testing applies the same ideas directly to endpoints, including GraphQL, where introspection, batching and authorisation per field create particular risks.
How the Categories Chain Together
Real attacks rarely rely on one flaw. Consider this realistic chain:
Information gathering reveals an old staging subdomain.
Configuration testing shows the staging site has verbose errors and default credentials.
Authentication testing gives access to a low privilege account.
Authorization testing reveals an insecure object reference that exposes other users' records.
Input validation testing finds an injection point in an export feature.
The combination exposes the production database schema.
Each flaw alone might be rated low or medium. Together they form a critical path. Strong testers think in chains and strong reports describe them. Practicing on a realistic target, such as the web application hacking lab, helps you see how the categories connect.
Conclusion
The OWASP WSTG categories are more than a table of contents. They are a deliberate sequence that moves from learning about a target, through the environment, identities and sessions, to the data flowing through the application and the protections wrapped around it. Understanding what each category tests and how findings in one feed into another, turns a list of techniques into a genuine methodology.
For testers, the lesson is to think in chains and document each step. For developers, it is to treat each category as a design question: have we limited what we expose, hardened our configuration, verified identity carefully, enforced access on the server, protected sessions, handled input in context, hidden our internals in errors and used cryptography properly?Pick the category where you feel least confident and spend a week on it. Reproduce the techniques in a lab, read the related code and write your own checklist. For a structured place to practise, start from the AppSecMaster home page and work through the labs one weakness at a time.
Frequently Asked Questions (FAQs)
How many testing categories does the OWASP WSTG have?
The widely used 4.2 release groups its content into twelve categories: information gathering, configuration and deployment management, identity management, authentication, authorization, session management, input validation, error handling, weak cryptography, business logic, clientside and API testing. Newer builds may reorganise these, so check the current release.
Which WSTG category should I test first?
Start with information gathering. It builds the map of entry points, technologies and roles that all later testing depends on. Skipping it usually leads to missed attack surfaces and wasted time.
What is the difference between authentication and authorization testing?
Authentication testing checks how the application verifies identity, such as login, passwords, lockout and recovery. Authorization testing checks what an authenticated user is permitted to do, such as accessing other users' data or administrative functions.
Why is input validation testing such a large category?
Because applications accept data through many channels and use it in many contexts, including HTML, SQL, operating system commands and XML. Each context creates its own risks, so the guide covers many injection and parsing weaknesses. The OWASP Top 10 guide explains how injection fits into the wider risk picture.
Can automated tools cover all WSTG categories?
No. Tools handle headers, known component versions and some injection points well, but struggle with business logic, multi role authorization and chained attacks. A combination of automated scanning and manual testing gives the best coverage.
