Web Application Exploitation
Map before you break
Effective web testing begins with attack surface mapping: authentication mechanisms, session handling, roles and privilege boundaries, API endpoints, input sinks, file handling, and third-party integrations. Test both authenticated and unauthenticated states, and with at least two accounts of different privilege so that authorization flaws (IDOR/BOLA, forced browsing, function-level access control) can be proven rather than suspected.
Core vulnerability classes
Injection (SQL, command, template, LDAP), cross-site scripting (reflected, stored, DOM), server-side request forgery, XML external entity, insecure deserialisation, file upload and path traversal, JWT weaknesses (algorithm confusion, missing signature verification, weak secret), CSRF, and business logic abuse such as price manipulation or workflow bypass. Each needs a payload that demonstrates real impact on that specific application.
Traps in exam questions
- Claiming stored XSS from a reflected-only vector, or claiming XSS impact where no session or sensitive action is reachable.
- Reporting IDOR from a single account without demonstrating access to another user's object.
- SSRF behind an allowlist - the answer is usually a redirect, DNS rebinding, or alternate URL parser, not brute force.
- Treating a 403 as proof of safety rather than a hint about routing.
- Time-based blind injection judged from one slow response instead of a repeated, controlled baseline.
Rule of thumb
Prove the maximum impact with the minimum invasiveness. SELECT @@version, a single alert-equivalent callback, or reading one file - never data modification, never a mass defacement payload.
Worked example: an API returns another customer's invoice when the numeric id is incremented. You note both accounts, capture the request and the returned object with the other account's identifier, and stop - you do not enumerate the full id space.