Web Application Pentest Methodology (OWASP WSTG)

Veyra has commissioned a penetration test of its online banking portal ahead of a new feature launch. Unlike the red team engagement in the Advanced Red Teaming course, this is a focused, methodology-driven assessment of one application — and the OWASP Web Security Testing Guide (WSTG) is the structure that keeps it thorough instead of ad hoc.

Why methodology beats intuition

An experienced tester poking at a login form for interesting behavior will find some real bugs. A tester following WSTG's structured categories - information gathering, configuration and deployment management, authentication, authorization, session management, input validation, business logic - finds the bugs the first approach misses, because coverage isn't left to instinct. For a regulated financial application, an assessment report has to demonstrate coverage, not just list whatever was found.

Information gathering: mapping before attacking

Before a single payload is sent, the target is mapped: every endpoint reachable from the authenticated and unauthenticated states, every parameter each endpoint accepts, the technology stack (revealed by response headers, error messages, and framework-specific artifacts like default file paths), and any exposed configuration - a .git directory left accessible, verbose error pages leaking a stack trace, an API documentation endpoint left public in production. On Veyra's portal, this phase alone surfaces a staging subdomain still pointing at a build with debug mode enabled - a finding before any real testing has even started.

Configuration review: the boring findings that matter

Missing security headers (Content-Security-Policy, X-Frame-Options, Strict-Transport-Security), permissive CORS configuration, and outdated TLS cipher suites don't make for an exciting report section, but they're frequently what turns a contained bug into an exploitable one - a reflected XSS is far more dangerous without a CSP to contain it.

Structuring the engagement

Testing proceeds in the same order WSTG lays out: passive review, then authentication and session management (since almost everything downstream depends on understanding how identity works in the app), then authorization, then the input-validation-heavy categories (injection, XSS), then business logic last - because business logic flaws only make sense once you understand what the application is supposed to do.

On the job: A methodology isn't a constraint on creativity - it's what guarantees that when the report says "authentication was tested," it actually was, thoroughly, not just glanced at on the way to something more interesting.