OSWE and WEB-300: a practical technical review guide
OSWE requires white-box analysis and exploit development. Build a code review workflow for data tracing, debugging and WEB-300 preparation.
- AUTHOR
- Karol Rapacz / CEO of Breachroad · OSCP · PNPT
- PUBLISHED
- 25 June 2026
- READING TIME
- 11 min read
- TOPIC
- Careers and Certifications
OSWE and WEB-300 focus on white-box web exploitation: candidates analyse source, discover a complex vulnerability path and build a working exploit. The current OSWE technical period is 47 hours and 45 minutes, followed by 24 hours for documentation.
Unlike black-box testing, HTTP output is not the only source of truth. Data must be traced through routing, validation, business logic and a dangerous sink.
Map the application
The first repository pass should answer:
- where routes and controllers are defined;
- how authentication and sessions work;
- where object authorisation occurs;
- which functions touch files, templates, XML, commands and databases;
- how configuration and secrets are loaded.
Run the application locally, capture one normal request and connect it to a controller breakpoint. Static search without runtime observation creates false paths easily.
Trace source to sink
Searching for exec, eval or query is only a start. For each sink, establish attacker control, transformations and guards.
A useful path record is:
source: POST /import name
transform: URL decode -> regex replace
guard: role=user, extension allowlist
sink: template render / file write
control: partial after normalization
Pay attention to order: validation before decoding, authorisation before identifier replacement and regex checks before normalisation.
WEB-300 vulnerability classes
The official syllabus includes upload restriction bypasses, PHP type juggling, magic hashes, PostgreSQL extensions and UDFs, regex and character bypasses, SSTI, weak tokens, XXE, database-function RCE and command injection through WebSockets.
Do not memorise them as payloads. Build a minimal vulnerable application, fix and regression test for every class. This teaches conditions rather than strings.
Debugging controlled experiments
Set breakpoints around validation and at the sink. Change one input at a time. Record type, value and encoding at each stage. In loosely typed languages, inspect conversions and comparison semantics.
For weak randomness, collect a token sample and reproduce the generator. For race conditions, measure timing and the race prerequisite instead of increasing threads indefinitely.
Automate the exploit
After manual confirmation, write a script that:
- checks target availability and version;
- creates or authenticates a session;
- obtains dynamic tokens;
- executes stages with error handling;
- validates the effect independently;
- preserves requests for reporting.
Stop when an assumption fails. An exploit that reports success without validation is worse than a manual PoC.
Preparation plan
Master reading one backend stack, then add another. Analyse one small project each week without a vulnerability hint. Timebox architecture mapping to two hours and an exploit hypothesis to four.
Practise reporting at the same time. OSWE requires reproducible explanation and code, not only a discovered bug. OWASP ASVS helps connect the root cause with a remediation requirement.
Readiness
You are ready when you can enter an unfamiliar project, run it, map a request flow and build a reliable exploit without a walkthrough. Knowing vulnerability names is insufficient; OSWE tests the path from code to demonstrated impact.
For the broader route, compare OSEP, OSWE and OSED. Take WEB-300 when code review is a regularly exercised skill rather than a one-time sprint before the exam.
A method for tracing data flow
Start at user-controlled input and trace normalisation, validation, data access and the sink. In parallel, trace authorisation: who establishes identity, where the object is selected and whether the control survives a direct endpoint call. Record file, function, condition and hypothesis to avoid rereading the same code.
After finding a flaw, produce a minimal repeatable proof and root-cause explanation. Practise across languages and frameworks while learning patterns, not payload lists. Check the latest syllabus and Exam Guide before the exam; OffSec documentation is authoritative for reporting and environment rules.
Sources: WEB-300 Syllabus, OffSec OSWE Exam Guide.


