Overview
The testing phase applies the vulnerability knowledge from the whole path to the mapped attack surface — methodically probing each input and function for weaknesses, within authorized scope. This lesson covers the testing phase.
Learning objectives
- Describe how testing proceeds against the mapped surface.
- Connect testing to the vulnerability classes covered earlier.
- Emphasize methodical, in-scope, safe testing.
Core concept
Testing systematically examines each mapped endpoint, input, and function for the vulnerability classes covered in this path — access control (authorization, BOLA/IDOR), injection (SQLi, command injection), XSS, CSRF, file upload, path traversal, SSRF, XXE, authentication/session flaws, security-header gaps, and API-specific issues. It follows the map as a checklist and applies the appropriate tests to each point, staying strictly within scope and using non-destructive techniques appropriate to the engagement.
How it works
For each mapped input/function, the tester applies relevant checks derived from the vulnerability modules: does an object-referencing endpoint enforce object-level authorization? Does an input that reaches a query use parameterization (test for injection safely)? Is user-reflected output encoded (XSS)? Are state-changing requests CSRF-protected? Is the upload feature safe? Testing is methodical (guided by the map, covering the surface) and careful (within scope, avoiding destructive actions, respecting rules). Findings are recorded with the evidence needed to demonstrate and reproduce them (next lesson).
Practical example
Working through the map, the tester examines /api/orders/{id} for broken object-level authorization (attempting, within scope, to access another user's order), checks /search for XSS and injection safety, verifies state-changing endpoints require CSRF protection, and reviews response security headers. Each mapped point gets the tests its type warrants, using controlled, non-destructive methods. Confirmed issues are documented with reproduction steps and evidence for the reporting phase.
Cybersecurity relevance
The testing phase is where the path's vulnerability knowledge is operationalized against a real (authorized) target, methodically and safely. Following a methodology like OWASP's ensures coverage (every mapped point tested), consistency (repeatable results), and professionalism (in-scope, non-destructive, well-evidenced). It reinforces that offensive techniques are used only within authorization, and that the goal is to identify and help remediate weaknesses — not to cause harm. Testing feeds directly into evidence collection and remediation guidance.
Common mistakes
- Ad hoc testing not guided by the map, leaving gaps in coverage.
- Straying out of scope or using destructive techniques not permitted by the rules.
- Not recording reproduction steps/evidence as findings are discovered.
Key takeaways
- Testing methodically probes each mapped input/function for the path's vulnerability classes, guided by the application map as a checklist.
- It applies the appropriate checks per point (authorization, injection, XSS, CSRF, upload, traversal, SSRF, XXE, auth/session, headers, API issues), staying in scope and non-destructive.
- The phase operationalizes the path's knowledge safely and professionally, feeding evidence collection and remediation.
Check your understanding
- How does the application map guide the testing phase toward comprehensive coverage?
- Why must the testing phase remain within scope and use non-destructive techniques?