OSWE Impressions 2026!

index

Right, another OffSec review. Like always, I’ll not be hand-holding but just giving my opinion on the course/exam and some general tips throughout the blog. If you have any specific question, feel free to reach out on my socials and I’m always happy to talk.

This past week, I took on the OSWE challenge. Always wanting to know what’s actually happening inside a web application. Not send this payload, get this response - I mean the bit underneath. Why does this parameter end up in that query? What is the framework doing between the request landing and the response going out? I’ve spent quite a few of my initial years poking at applications from the outside and feeling like black-box is a lot of guesswork.

FYI, I didn’t come into this knowing nothing. Web application pentesting is an important part of my day job, and I’ve spent a good chunk of my free time on CTFs - or I did, before AI turned up and took most of the fun out of them. I’ve also built a fair number of vulnerable labs myself, which teaches you a surprising amount about how these bugs get introduced in the first place.

Certification-wise, I went in already holding BSCP, CPTS and PNPT that have taught me a fair chunk of web application security.

I mention all that because it’s the point. Even with the day job, the labs and the certs behind me, OSWE still taught me tricks and techniques about web applciations in general. It’s one of the first things I’ve done that closed that gap. I guess we are all learning time and time again after all!

Whitebox Changes Everything

The pitch is simple: you get the source code on the Debug machine and a Victim machine where you are supposed to replicate the entire attack chain.

Blackbox testing trains you to pattern-match and get the feel of the application. You learn what is intended and what is suspicious. Whitebox forces you to actually read the thing and follow data from where it enters to where it does damage, basically tracing the user-controlled data through files and functions and watch it land somewhere it had no business being, something clicked that no amount of blackbox practice had managed.

Tip

Get comfortable reading code you didn’t write and don’t fully understand. Not just writing it - reading it. That’s the actual skill this course is testing, and it’s the one people underestimate.

You work through quite a few languages including .NET, Java, PHP and nodeJS applications. That spread may look intimidating but will stop mattering after about a week. Keep in mind, you’re not learning four languages - you’re learning to find the same handful of mistakes wherever they happen to be hiding. Obviously, if you wish you can definitely go into the course having brushed up on a few of the above which will save you a good chunk of time.

Credit where it’s due on the structure as well: the course starts from the very basics and builds up properly. It doesn’t assume you already know how to review source code.

The Scripting

This was my favourite part of the whole thing especially since I used to do a wee bit of CP back in the day but that was in C++.

Anyway, as for OSWE you can’t hand in a pile of manual steps. You’re expected to chain the whole exploit into a single standalone script that runs start to finish. That’s a completely different discipline from finding the bug. Suddenly you care about session handling, about what happens when a response comes back in the wrong order, about your script failing without you knowing where to trace the point of failure.

Every PoC needs the same furniture though - argument parsing, a session that holds cookies properly, somewhere to catch callbacks, a way to serve a payload. I used cookiecutter-poc for every exploit I wrote during the course and the exam. Shoutout to Kyle!

The Challenge Labs

These were the best part of the course, no contest.

At the time of me doing my course there were around 7 with Offsec - Answers, chat, erka, docedit, gallery, notebook and Squeakr. For additional labs you can have a look at bmdyy’s TUDO application, or @TJ_Null’s OSWE Prep (this may be overkill). I personally just binge watched the prep list video but didn’t get my hands dirty on any of them.

The Exam

The exam was rather easier than I expected. I started at around 8th August, 2026 1 PM British time and the next day 6 AM I had a perfect score with semi-partial working scripts.

I’m not going to say anything about the content, obviously. OffSec would have my head, and you already know that. Also, the pressure is comparatively less when you go into the exam knowing that the app is vulnerable and that you also have the source code. A few tips can be:

Write your code snippets/helper scripts beforehand or use what I described in the previous section
Try to complete all the course/challenge labs. In most cases, challenge labs are former retired exam sets.
Approach the app with black box pov. and by this deep into the course/exam your spidey sense should tingle if something is out of place.
Another way, I feel I’ve improved my skills is by just reading bug bounty blogs/articles. I’ve attached a few in the “Further Reading” section if you guys would be interested.

Where It Falls Short

It’s good. It isn’t perfect.

The case studies lean heavily on specific applications and specific CVEs, which means some of it reads as dated the moment you look at what modern web stacks actually look like. There’s not much here that prepares you for the things you may run into like - modern SPA apps, GraphQL, and messier auth flows like OAuth etc.

For all the talk about methodology, some modules also quietly skip the hard part. The ManageEngine chapter is the clearest example - you build a regex to find every SQL query in the codebase, get back a hundred-odd results, the first one needs authentication so you keep looking, and then eventually the vulnerable route turns up. Eventually? How? By hand, or with better regex? Narrowing a hundred candidate routes down to the one that matters is the entire skill, and it’s exactly the bit that gets glossed over.

A fair amount of it doesn’t survive contact with the cloud either. File upload bugs matter far less when an application is cloud-native to begin with, and SSRF is a much smaller problem against a properly hardened EC2 instance. Add in how few distinct vulnerability classes actually get covered - there are at least three separate SQL injection examples - and you shouldn’t expect to walk out of this and start finding these exact chains in the wild. Still worth working through, just set your expectations accordingly.

Final Thoughts

I’m not going to talk about the price. We all know what OffSec charges, and if you’ve got this far into a review you’ve already had that particular heart attack. You know what it costs, you know whether it’s coming out of your pocket or someone else’s, and there’s nothing I can add that your bank balance hasn’t already told you.

If you want to stop guessing at web applications and start reading them, this is the most direct route I’ve found. It fixed something in how I approach targets that I’d been aware of for years and hadn’t managed to fix on my own. That’s worth something to me that’s hard to put in a number.

And if the price does rule it out, the skills themselves aren’t locked behind it:

Build your own vulnerable labs!!!
CWEE by Hack The Box
PortSwigger Web Security Academy never disappoints
PentesterLab Code Review badge for standalone vulns

Just go in knowing what it is: a very good course at teaching you to read code and chain bugs, and a slightly dated one at reflecting the web as it exists in 2026.