OSWE failures are rarely about missing a vulnerability. The exam gives you source code, so the flaw is usually findable. What separates a pass from a retake is what happens between finding the flaw and submitting the report — and that is where these mistakes live.
1. Starting in the browser instead of the code
The browser shows you what the application exposes. The code shows you what it hides. Candidates who begin with manual testing find the surface bugs, then plateau, because the intended path is usually in a route the UI does not link to or a handler that validates on one path and not another.
Start with the route map. Then read the controllers. Use the browser to confirm, not to discover.
2. Not mapping the routes
Reading a codebase file by file is slow and produces fragments. Reading from the entry points down is fast and produces a path.
Build the map first: every route, its handler, its middleware, and the authentication requirement. Ten minutes of this prevents two hours of reading files that are not reachable from your position.
3. Skipping the authentication layer
Authentication and session handling are where the highest-value bugs hide: token generation, password reset logic, remember-me cookies, JWT validation, and role checks that exist in the UI but not in the API.
Read the authentication code before the business logic. It is the gate everything else sits behind, and gaps there turn a low-impact bug into full access.
4. Treating a proof of concept as an exploit
A request in Burp that works once is evidence of a bug. The exam asks for a custom exploit — code that performs the attack reliably. If the reviewer has to reconstruct your session, tokens, and manual steps, the deliverable is incomplete.
Write the script at the moment of success. It will never be easier than when the flow is fresh.
5. Hardcoding values that expire
A script that contains a session cookie or a CSRF token works until it does not. Under exam conditions, this failure appears at the worst moment: during your final verification.
Build the exploit to obtain its own session, extract its own tokens, and re-authenticate when the response indicates expiry. Then run it twice from a clean state before you trust it.
6. Explaining the payload instead of the flaw
“Used a .NET deserialization gadget” describes the tool, not the vulnerability. The report needs the code path: which input is deserialized, which type check is missing, and why the chain reaches execution.
A useful test: if you removed the payload from your explanation, would the reviewer still understand how the application is broken? If not, the analysis is incomplete.
7. Ignoring the evidence requirement
Each objective needs proof. A screenshot of a shell without the host and the command that produced it is weaker than it looks, and grading can reduce or zero an objective for missing documentation.
Capture in a consistent format: command, output, host context, and the objective file. Do it when it happens.
8. Forgetting that machines connect
OSWE targets are not fully independent. Credentials, files, and access obtained on one machine often unlock the next. Candidates who treat each host as a separate puzzle finish the easy ones and stall on the chain.
Keep a running inventory of credentials, keys, session tokens, and network reach. Re-read it after every success.
9. Overfitting to one framework
Practising only on one stack — say, PHP applications — leaves you slow when the exam target is Java, .NET, or Node. The vulnerability classes transfer; the syntax, routing conventions, and dangerous functions do not.
Rotate stacks during preparation. Read at least one application per language family, even if you only exploit it in a lab.
10. Treating the report as an afterthought
This is the most expensive mistake because it affects every objective at once. A technical report with exploit code takes eight to twelve hours. Candidates who start at hour forty submit something rushed and lose points they had already earned.
Draft as you go. Four minutes per finding when it happens, forty when reconstructed.
11. No sleep plan
Forty-eight hours is not a sprint, and accuracy degrades in a way that is invisible from the inside. Exploit code written at hour thirty often works in the moment and fails on review. A six-hour sleep block is part of the plan, not a concession.
12. Exploring after the objectives are met
The objectives are finite. Curiosity is not. Once the required targets and proofs are complete, the highest-value work is verification and documentation, not one more machine.
A pre-submission checklist
- Every objective has a proof file and a screenshot with host context.
- Every exploit runs from a clean state.
- Every finding explains the code path, not just the payload.
- The report follows the required structure.
- Scripts are included and readable.
- The archive format and filename match the requirements.
Where to go next
For the certification overview and study material, see the OSWE certification hub. For the exam structure and a five-week plan, read OSWE exam: 48 hours, source review and a custom exploit. For pacing across the two days, see OSWE exam experience.
Certification names belong to OffSec. This is independent study material, not official course content.
Web application security specialist and bug bounty hunter. OSWA and OSWE certified, focused on web exploitation, API security and source-code review. Writes our web exploitation walkthroughs and reviews report structure for web-focused certifications.