OSWA and WEB-200: a practical exam preparation guide
OSWA tests practical web application penetration testing. Learn the WEB-200 format, Burp workflow, reporting method and exam readiness criteria.
- AUTHOR
- Karol Rapacz / CEO of Breachroad · OSCP · PNPT
- PUBLISHED
- 21 June 2026
- READING TIME
- 9 min read
- TOPIC
- Careers and Certifications
OSWA and WEB-200 teach practical web testing before the deeper white-box focus of OSWE. The proctored exam lasts 23 hours and 45 minutes, followed by 24 hours for documentation.
Skills in scope
Candidates should understand HTTP, sessions, authentication, access control, injection, uploads, traversal, XSS and business-logic weaknesses. A proxy exposes traffic, while success depends on systematic request manipulation.
Map roles, endpoints, objects, identifiers and trust boundaries. For every request, ask what can be changed, removed, replayed or submitted as another identity.
Testing workflow
Walk the legitimate flow as each role. Then test object and function authorisation, server-side validation, encoding and HTTP method differences. Separate discovery from exploitation: a minimal PoC should prove impact without unnecessary damage.
Track endpoint, parameter, role, expected control, result and evidence. This prevents missed sibling functions and accelerates reporting.
Readiness
Complete labs without hints and without knowing the vulnerability category in advance. Identify vectors from application behaviour rather than a training-module title.
OffSec permits notes and online sources while excluding direct chatbot and LLM use. Re-read current rules before the exam.
OSWA is a useful step toward OSWE. Add OWASP ASVS to connect every finding with a remediation requirement.
Systematic application enumeration
Build a map of features, roles and business objects first. Browse the application while unauthenticated and authenticated, recording endpoints, parameters, HTTP methods, data types and response differences. Proxy history is source material; an organised manual map is what reveals where to test access control, data processing and trust boundaries.
For every parameter, determine where it originates and where it is used. An object identifier, query fragment, filename, server-fetched URL and HTML value require different hypotheses. Do not begin with a random payload list. Define the expected signal, make the smallest useful input change, and compare status, length, body, timing and persistent state.
Confirming rather than merely detecting
A scanner result or one error message is a lead. Confirm a vulnerability with a controlled proof that demonstrates a confidentiality, integrity or availability impact without unnecessary actions. For access-control tests, compare at least two user contexts. For server-side issues, distinguish application behaviour from network, cache or protective controls.
Maintain a compact table: hypothesis, baseline request, modification, observation, conclusion and status. Rejected hypotheses still matter because they prevent duplicated work under time pressure.
Timed practice
Divide a session into mapping, high-probability tests, deeper analysis and a final evidence review. Each week, assess an unfamiliar application without being told the vulnerability category. During the retrospective, identify late signals, cluttered proxy history and tests that lacked a defined purpose.
Before the exam, verify proctoring, environment stability, evidence export and the current tool restrictions. Technical skill cannot recover missing proof or a rules violation.
A single-endpoint checklist
Before closing analysis, test whether the endpoint behaves differently without a session, with lower and higher roles, and with an object owned by another user. Compare method, content type, missing and repeated parameters, boundary values and predictable identifiers. For asynchronous operations, verify the final state rather than only the first HTTP response.
For text inputs, identify the use context: HTML, JavaScript, SQL, filesystem, command, template or outbound request. For uploads, assess extension, MIME, filename, storage location and subsequent delivery. Authentication testing should include password reset, email changes, logout and session invalidation.
Finish with an explicit status: confirmed, rejected or unverifiable because of a stated limitation. That conclusion is more useful than a long payload list without a finding.
Periodically review your notes as the engineer responsible for remediation. If they do not identify the exact vulnerable condition and the expected safe behaviour after a fix, the analysis is incomplete. This habit prepares you for professional web-assessment reporting as well as the exam.
Sources: OffSec OSWA Exam Guide, OSWA Exam FAQ.
