How I Passed the Burp Suite Certified Practitioner Exam — On My Second Try

Hello everyone, my name is Eljan, and today I want to tell you the story of how I passed the Burp Suite Certified Practitioner Exam.. If you're preparing for the BSCP, or you've just failed it and you're wondering whether it's worth trying again — this is for you.

Where I started

My background is a lot less conventional — no computer science degree, no bootcamp, not even a finished traditional education.

So I built my own way instead. I started with Kali Linux, using tools without fully understanding what I was doing. Then I moved to TryHackMe, working through CTF-style challenges until the tools stopped feeling like magic and started feeling like instruments I could actually use. Eventually I landed on PortSwigger's Web Security Academy — free, deep, and exactly the kind of resource that rewards people who are willing to put in the hours without anyone checking their homework.

Months of labs later, I felt ready for the BSCP exam.

How I prepared

If you're getting ready for the BSCP yourself, here's what actually helped me a lot:

1. Go through every topic and solve the labs — at least up to Practitioner level. There are a lot of them, and yes, it takes time. But some of these labs open your eyes to genuinely useful information: interesting vulnerability types, unusual chains, edge cases you wouldn't think to look for otherwise. The solution patterns you build here are close to what shows up on the exam. Not identical, slightly reshaped, but the underlying logic is the same.

2. Take notes and document everything you do. I used Notion to keep my solutions and notes organized, and without that habit, both passing the exam and just finding the right payload for a given vulnerability becomes a lot harder. I also built my own GitHub web security cheatsheet along the way, which ended up being genuinely useful going into the exam itself.

For example, if I run into a CSRF vulnerability in an app, instead of spending 5–10 minutes searching for a payload that will work for exploitation, I just open my notes, find the CSRF section, and copy the payload.

Web Security Cheatsheet — https://github.com/eldzhanka/web-security-cheatsheets

**3. Take the practice exam PortSwigger gives you before the real one, and solve as many Mystery labs as you can.**They're honestly kind of fun to work through, and they're great for building muscle memory for specific vulnerability patterns ,something that pays off well beyond the exam itself.

4. What the exam involves. This part is publicly documented by PortSwigger themselves, so it's fair game to know going in: you get four hours, split across two separate applications, and each one is structured in three stages. Stage one is about getting access to any user account. Stage two is about using that access to reach the admin interface usually by escalating privileges or compromising the administrator account outright. Stage three is about using that admin access to retrieve a /home/carlos/secret file from the server's filesystem and submitting it as proof.

The first attempt

I won't get into the specifics of what's on the exam PortSwigger asks candidates not to share exam content, and honestly, figuring it out yourself is part of the value. What I can tell you is the shape of it: it's fully practical. No multiple choice, no theory questions to fall back on. You're given live, vulnerable applications and a limited window of time to actually break them, chain your findings, and prove exploitation not just identify a bug and describe it in theory.

That format is exactly why the certification means something. You can't memorize your way through it.

My first attempt ended in failure. Not a distant, "I had no idea what I was doing" failure — I was close. I fully solved the first application, and made it all the way through the second one too, right up until the last stage. I just couldn't get that final file read to go through in time. That kind of failure is almost harder to sit with than a clean miss, because you replay it. You know the next step existed, somewhere just past the clock.

One thing I did during that attempt that I'd genuinely recommend: when I got stuck on a stage, I didn't sit there grinding at the same wall. I switched to the other application and worked on that instead, then came back to the spot where I got stuck later. Stepping away and coming back with fresh eyes made connections I'd missed the first time much easier to spot.

I'd also recommend launching your scanners early as soon as you spot a parameter that looks like it could be vulnerable, throw a scan at it right away rather than waiting until you've manually exhausted your ideas. Let the scanner work in the background while you keep testing manually; it often catches something before you'd have found it by hand.

Also, be aware that rabbit holes are real. Not everything that looks promising actually leads anywhere, and it's easy to burn thirty minutes chasing something that was never going to pan out. If you've a lot of time on a lead with nothing to show for it, that's usually your cue to step back and try a different angle which ties back into switching applications when you're stuck.

Sending an email I almost didn't send

Retaking the exam isn't automatically free — usually a new attempt means paying again. I didn't have a strong expectation that reaching out would change anything. But I figured the worst they could say was no, so I wrote to PortSwigger support anyway, explained where I'd gotten to, and asked.

They told me this isn't something they normally do. But because I had gotten so close on my first try, they made an exception and gave me a free retake.

Never be afraid to reach out and ask about things like this — the worst outcome is usually just a "no"

The second attempt

I went back in with a clearer head. I'd already seen the format, already felt the time pressure, already knew what it was like to be one step short. That experience alone changed how I approached the second attempt — less time spent getting oriented, more time spent executing.

This time, I passed.

What I'd tell someone preparing for this exam

Expect to fail, and don't treat it as a verdict on your ability. The exam is known for being hard even for people with real industry experience — plenty of experienced testers take multiple attempts before passing. A failure here tells you about the exam's difficulty, not about whether you belong in this field.

1. Do the labs properly, not quickly. The Web Security Academy content works because it's hands-on. Rushing through it to "finish" defeats the purpose — the exam rewards instinct built from repetition, not a checklist you completed once.

2. Time management is its own skill, separate from technical knowledge. Knowing how to find and exploit a vulnerability isn't the same as doing it fast enough, under pressure, while still thinking clearly about what to try next if your first approach stalls. Practice under a clock before the real thing.

3. If there's a reasonable ask on the table, make it. Whether that's a support team, a mentor, or anyone else — the underlying lesson is the same. I almost didn't email PortSwigger because I assumed it wouldn't matter. It did.

4. Don't let "no formal background" become a story you tell yourself. I didn't come from a CS program or a security bootcamp. What got me here was time spent in Kali, in TryHackMe rooms, and in PortSwigger labs — not a credential I walked in with.

Where I'm headed next

BSCP isn't the finish line — it's the credential that got me a foot in the door. I'm currently building out my GitHub with security tooling and notes, writing more about what I'm learning, and looking for my first role as a junior web penetration tester. If you're on a similar path, or you've got advice for someone trying to break into this field without a traditional background, I'd genuinely like to hear from you.

I write about my path into web security and penetration testing. You can find my projects and notes on GitHub, or connect with me on LinkedIn.