OSWA study materials
OSWA study resources

OSWA: Web Application Reconnaissance and Enumeration

OSWA · Work through your exam, one topic at a time.

All guide sections

Web Application Reconnaissance and Enumeration

This domain tests whether you can turn a single URL into a working inventory of hosts, paths, parameters, technologies, and roles before you send a single exploit payload. The exam rewards methodical mapping and penalises reporting wildcard noise as findings.

Core rules and concepts

  • Fingerprint first: Server, X-Powered-By, cookie names, error-page formats, favicon hashes, and JavaScript framework artefacts all narrow the wordlist and extension set.
  • Content discovery uses ffuf, feroxbuster, or gobuster with status, size, word, and line filters. Recurse on hits and try stack-appropriate extensions (.php, .aspx, .jsp, .bak, .old).
  • Virtual-host enumeration fuzzes the Host header against a baseline response; an admin application can hide on the same IP.
  • Parameter discovery combines form parsing, Arjun-style fuzzing, and grepping JavaScript bundles, source maps, robots.txt, sitemap.xml, and exposed .git/ for endpoint strings.
  • Historical sources - Wayback URLs and certificate transparency - often reveal forgotten subdomains and endpoints.

Worked example

The main application returns HTTP 200 for every path. Send a baseline request to /zzz-<random> and record the response size, 4,312 bytes. Run ffuf -w list.txt -u https://target/FUZZ -fs 4312; the filter removes soft-404 noise and exposes /api/v2/ at 187 bytes. Fetch /api/v2/, read the referenced app.js, and find /api/v2/users?role=admin. Requesting it unauthenticated returns 401, which confirms the endpoint exists. Next, fuzz vhosts with -H "Host: FUZZ.target" against the same size filter and discover internal.target serving a login page. Reasoning: size filtering eliminated false positives, JavaScript disclosed the parameter, and vhost fuzzing exposed a separate attack surface.

Traps that cost marks

  • Not establishing a wildcard/soft-404 baseline, then reporting dozens of fake 200s.
  • Ignoring 401 and 403 responses, which confirm a resource exists.
  • Using one wordlist and one extension, and never checking backup or config files.
  • Skipping vhost and parameter enumeration entirely.
  • Trusting client-side route lists without requesting each route server-side.