Web Application Reconnaissance and Enumeration
Web Application Reconnaissance and Enumeration is where CWEE expects you to map an application before touching exploit logic. The exam tests whether you can turn scattered HTTP responses, JavaScript, and DNS data into an attack surface you can explain.
Build an asset and route inventory
Start with what the app tells you: response headers, cookie names, error pages, robots.txt, sitemap.xml, and TLS certificate names. Then enumerate virtual hosts and API versions. Treat every JavaScript bundle as documentation: search for fetch and axios calls, GraphQL operation names, feature flags, internal hostnames, and parameter names. Use exposed source maps when present. Fuzz parameters, not just directories, and compare authenticated versus unauthenticated responses.
Classify findings
Record each endpoint with method, auth requirement, accepted content type, and observed roles. Note 401 versus 403, 200 with an empty body, and redirects; these distinctions guide later access-control tests.
Worked example
A homepage loads /static/app.9f2c.js. Grepping it reveals fetch('/api/v2/users/'+id+'/documents') and an admin flag. Requesting the endpoint unauthenticated returns 401; with a low-privilege cookie it returns another user's document metadata. That is a candidate IDOR, not a confirmed one until object ownership is tested.
Traps
Directory brute forcing alone misses parameter and API routes. Assuming a 403 is unexploitable ignores method and path-normalization tricks. Ignoring JavaScript source maps and GraphQL operation names leaves the best routes hidden.