How do you structure a web application test using the OWASP WSTG?
Short answer
The WSTG is a checklist-backed methodology that walks an app through testing categories: information gathering, configuration and deployment, identity and authentication, authorization, session management, input validation (injection/XSS), error handling, cryptography, business logic, and client-side. It gives systematic coverage with stable test IDs so findings are reproducible and nothing obvious gets skipped.
The OWASP Web Security Testing Guide (WSTG) turns "test the web app" into a systematic, repeatable process. Interviewers reach for it because an experienced tester does not poke at random URLs — they work a structured set of categories so coverage is provable and findings carry stable identifiers others can reproduce.
The testing categories
WSTG organizes testing into a logical progression:
- Information gathering. Fingerprint the server, frameworks, entry points, and map the application's attack surface.
- Configuration and deployment management. TLS, HTTP headers, default files, admin interfaces, cloud and infra misconfigurations.
- Identity and authentication. Account enumeration, weak credential policies, MFA bypass, password-recovery flaws.
- Authorization. Privilege escalation, insecure direct object references (IDOR), path traversal — does the app enforce who can do what?
- Session management. Token strength, fixation, logout, cookie attributes.
- Input validation. The classic injection family — SQLi, XSS, SSRF, command injection.
- Error handling and cryptography. Information leakage, weak ciphers, improper key handling.
- Business logic. Abuse of legitimate features — the flaws scanners cannot find.
- Client-side. DOM XSS, CORS, postMessage, and JavaScript issues that live in the browser.
Why the structure matters
The categories impose coverage: a scanner finds reflected XSS but never understands that "skip the payment step and still get the goods" is the real bug. The stable test IDs (e.g., WSTG-ATHZ) let you map findings, track progress, and hand a remediation team something reproducible.
What interviewers look for
They want to see you blend automation with manual depth — using DAST to clear breadth, then spending human time on authorization and business logic, the categories that genuinely require a thinking attacker.
Likely follow-ups
- How do you test business-logic flaws that scanners can't find?
- What's the difference between authentication and authorization testing in WSTG?
- How would you combine WSTG with automated DAST without drowning in false positives?