My Journey into Web Application Security with PortSwigger

A few months ago, I sat in front of my laptop, staring at a Burp Suite proxy log filled with requests and responses that meant almost nothing to me. I had just finished a cybersecurity training program, my head full of terms like SQL injection, XSS, and IDOR, but something felt incomplete. I could recite definitions. I could not yet think like the systems I was supposed to be defending.

That gap between knowing the words and understanding the reasoning is where this series begins.

After little observation in work surrounding what struck me early on is how differently people talk about the same vulnerability depending on which room they're standing in. A developer calls it a bug. A penetration tester calls it a finding. An auditor calls it a control gap. A compliance officer maps it to a clause number. Everyone is technically correct, and yet these conversations rarely seem to connect. I remember sitting in a training session where an instructor explained SQL injection purely from an attacker's perspective telling how to break out of a query, how to enumerate a database at that time I found it genuinely fascinating. But afterward I kept thinking, how can a developer actually stop this from happening in the first place? Not "use parameterized queries" as a throwaway line, but why that specific fix works, and what happens if a team can't apply it immediately, and what an auditor would actually check to verify it's been done properly.

That question kept following me around.

Why web applications, and why now

It's almost a cliché to say that everything runs on web applications now, but it's the truth as well. Your bank, your hospital's patient portal, the internal tool your HR department uses to process your leave requests etc these are all web applications, built by teams under deadlines, using some frameworks, connected to databases holding information that matters.

And yet, in a lot of the organizations I've read about, talked to people from, or seen firsthand, secure coding is still treated as something you circle back to. Security gets folded into the process late, sometimes at a penetration test right before launch, sometimes only after an incident. I don't say this to sound cynical. I think most people writing code want to write it securely. The pressure just runs the other way. Deadlines don't move. And a vulnerability that exists conceptually on a whiteboard during a threat modeling session (if one even happens) doesn't feel as urgent as the ticket due Friday.

I'm not writing this series to lecture anyone about that. I'm writing it because I wanted a way to sit with each vulnerability class long enough to actually understand it from more than one angle. I figured if I was going to do that work for myself, I might as well write it down properly instead of leaving it in scattered notes I'll never reopen.

Why PortSwigger's Web Security Academy

If you've spent any time in application security, you've probably run into PortSwigger's labs. They're free, they're well structured, and they walk you through real vulnerable applications rather than toy examples. I started working through them somewhat randomly at first as per my mood and interest then I noticed a pattern in how I was learning.

I'd complete a lab, feel a small rush of satisfaction at getting the payload to work, and then move to the next one almost immediately. The exploitation stuck. The reasoning behind it didn't, not really. A week later I'd remember that I'd solved a particular SSRF lab, but I couldn't have explained cleanly why the vulnerable code was written the way it was, or what a code reviewer should have caught, or how that same flaw would show up differently in an audit report versus a bug bounty submission.

So I changed how I was approaching each lab. Instead of closing the tab once the lab showed "solved," I started asking myself a longer list of questions. What is actually happening at the HTTP level here? What does the vulnerable code probably look like on the backend? If I were reviewing this code before it shipped, what would I flag? If I were an auditor two years after deployment, what evidence would I want to see that this class of issue is being managed? What's the actual business risk if this gets exploited? Is this something you fix immediately, or something you accept temporarily with compensating controls while a proper fix gets scheduled?

That's a lot more work than just solving the lab. It's also, I think, the only way any of this actually sticks.

What this series is trying to be

I want to be upfront about something: I am not writing this as an expert. I've been in this field for a relatively short time, and there are people who have forgotten more about web application security than I currently know. What I do have is a fairly unusual advantage — I'm learning this material for the first time, deliberately, while also having been close enough to development, audit, and governance conversations to notice how rarely they overlap in the material most of us learn from.

So this series is my attempt to document each PortSwigger lab not as "here's the payload that worked," but as a fuller picture. For each vulnerability, I want to walk through the technical mechanics starting from what's happening in the request and response, what the Burp Suite workflow looks like, where exactly the logic breaks. But I also want to sit with the root cause long enough to explain it in a way a developer could actually use, reference the relevant OWASP guidance, think through how an auditor would approach the same issue, and talk about the kind of controls — preventive, detective, and the compensating ones you fall back on when the "correct" fix isn't immediately possible.

I also want this to be honest about where I'm uncertain. There will be labs where my read on the secure coding fix is solid, and others where I'm reasoning through unfamiliar territory and genuinely working it out as I write. I'd rather be transparent about that than pretend a level of confidence I haven't earned yet.

A moment that stuck with me

There was one lab, I think standard authentication bypass through logic flaws — that took me embarrassingly long to solve. Not because the exploit itself was complicated, but because I kept assuming the vulnerability had to be more sophisticated than it actually was. I was looking for something clever when the actual issue was almost mundane: a step in a multi-stage login process that could be skipped entirely if you just… didn't send the request for it.

What stayed with me afterward wasn't the technique. It was how ordinary the root cause turned out to be. Somewhere, a developer built a login flow assuming users would always move through it in order, front to back, because why wouldn't they? That assumption is completely reasonable from a UX perspective and completely wrong from a security perspective. It's not a story about a careless developer. It's a story about how easy it is to build software correctly for the way you expect it to be used, and how attackers make their living in the gap between expected use and actual use.

That's the kind of thing I want this series to capture and not just "this is broken, here's how," but the very human reasoning that leads to these gaps existing in the first place, because I think that's what actually helps people prevent them.

Who I think this might help

I'm writing this with a few different readers in mind, partly because I was thinking about several of these perspectives myself while working through the labs.

If you're new to cybersecurity, I hope walking through a vulnerability from multiple angles.

If you're a developer, I hope the secure coding angle is specific enough to actually be useful in a code review, not just a generic "validate your input" reminder.

If you're a penetration tester or security auditor, I hope seeing the audit and risk-assessment perspective alongside the exploitation technique gives you language to translate technical findings into something a risk committee will actually engage with.

If you're preparing for an interview or a certification, I hope having the reasoning laid out helps to increase your confidence about your knowledge.

Where this goes from here

This won't be a fast series, and I don't want it to be. Web Security Academy has an enormous number of labs across a wide range of vulnerability categories, and I'd rather take the time to actually think through each one properly than rush out a high volume of shallow write-ups. Some weeks there might be one article. Other weeks, a few, depending on how deep a particular topic ends up requiring.

I also expect my own understanding to visibly develop across this series, and I'm fine with that being visible rather than polished away. If you go back and compare an early article to one written months from now, I'd genuinely be a little disappointed if they read the same way. That would mean I hadn't actually learned anything in between.

If any of this resonates with you — if you've felt that same gap between solving a lab and actually understanding why it mattered, or if you're trying to connect the dots between development, testing, and governance in your own work — I'd like to invite you to follow along. Not as a finished course from someone who has it all figured out, but as a working notebook from someone documenting the process in real time. PortSwigger's Web Security Academy is where this series starts, but I don't intend to stop there — I'll be pulling in DVWA, OWASP Juice Shop, and other vulnerable-by-design platforms along the way, using each one as a different lens on the same underlying vulnerability classes.

If you've made it this far, thank you for reading the opening note of what I hope turns into a long, honest record of actually learning this field, rather than just performing that I already have. I'll see you in the next one…