What Is the PortSwigger Web Security Academy? A Beginner’s Guide

Someone asked me last week where they should even start with web application security, and I gave the same answer I always give now, which is: open PortSwigger's Web Security Academy and just start clicking through labs. It wasn't the answer I expected to be giving a few months ago. Back then I didn't know it existed either. But it's the single resource I keep coming back to, and since I've been documenting my own journey through it, it felt worth stepping back and actually explaining what it is, why it works the way it does, and why I think it deserves a place near the top of almost anyone's learning path in this field.

What it actually is

The Web Security Academy is a free, browser-based training platform built by PortSwigger, the company behind Burp Suite. That last detail matters more than it might seem at first. Because it's built by the same people who build the tool most penetration testers actually use day to day, the labs aren't abstract exercises designed by someone imagining what a vulnerability looks like — they're built by people who watch vulnerabilities get exploited for a living.

Structurally, it's organized around vulnerability categories. SQL injection has its own section. Cross-site scripting has its own section. So does access control, authentication, SSRF, XXE, and dozens of others. Each section starts with a written explanation of the vulnerability class — what it is, why it happens, what a vulnerable request or response might look like — and then hands you a series of labs that get progressively harder. You're given a real, running web application with a real vulnerability planted somewhere inside it, and your job is to find it and exploit it well enough that the platform recognizes you've solved the lab.

What struck me the first time I used it is that there's no simulation layer pretending to be a web app. It genuinely behaves like one. You get real HTTP requests, real cookies, real session handling, real quirks in how the server responds to malformed input. If you've spent any time in a classroom setting where vulnerabilities are explained through slides and diagrams, this is a different experience entirely. You're not reading about how SQL injection works. You're staring at a login form, trying an apostrophe in the username field, and watching the application actually break in front of you.

Why hands-on labs teach differently than theory

I want to be honest about something. Before I started working through these labs, I had already read a fair amount about common web vulnerabilities. I could have explained SQL injection to you in a training session and probably sounded reasonably competent doing it. But there's a very specific kind of understanding that only shows up once you've actually had to find a working payload against a live application that's actively trying to sanitize your input, or once you've had to figure out why a particular exploit worked on one lab but silently failed on the next one that looked almost identical.

That difference is subtle but it matters enormously. Reading that "improper input validation can lead to SQL injection" teaches you a fact. Sitting with a login form for twenty minutes, trying variation after variation of a UNION-based payload, watching the error messages change slightly each time you adjust something, and finally seeing the query execute — that teaches you a process. And application security is fundamentally about process. Real vulnerabilities rarely look exactly like the textbook example. They show up with unusual encoding, unexpected filtering, partial sanitization that blocks the obvious attack but leaves a gap three steps to the side of it. The only way I've found to build the instinct for finding that gap is to have actually gone looking for it, repeatedly, in slightly different conditions each time.

There's also something about the immediate feedback loop that I think matters more than people give it credit for. When a lab is solved, PortSwigger tells you immediately. When it isn't, you know immediately too, and you're left sitting with the problem instead of moving on. That tight loop between attempt and result is, I think, a big part of why hands-on practice sticks in a way that passive reading doesn't. You're not accumulating facts. You're building a felt sense of how these systems break.

Why web applications specifically deserve this level of attention

It's worth pausing on why web applications, out of everything a security professional could specialize in, warrant this much focus. The honest answer is that they're everywhere, and they've quietly become the connective tissue between organizations and the people who depend on them.

Think about how much of daily life now runs through a browser or an API behind one. Banking happens through web applications. So does healthcare, from patient portals to the systems clinicians use internally. Government services, increasingly, are web-first. Retail and e-commerce obviously run on them entirely. Even purely internal business processes — HR systems, ticketing platforms, internal dashboards — are almost always web applications now, because it's simply easier to build and maintain one web app than to distribute and update native software across an organization.

That ubiquity creates an enormous attack surface, and it's an attack surface that isn't going away or shrinking. Every new feature is potentially a new endpoint, a new parameter, a new place where user input meets business logic. And unlike some other areas of security where the attacker needs a foothold inside a network first, a huge number of web application vulnerabilities are reachable directly from the public internet, by anyone, at any time. That combination — everywhere, and often directly exposed — is exactly why I think web application security knowledge isn't a niche specialty anymore. It's closer to a baseline expectation.

And this is genuinely true across roles, not just for people with "penetration tester" in their title. A developer who understands how these vulnerabilities actually get exploited writes different code than one who's only been told to "avoid SQL injection" without ever seeing what that means in practice. A SOC analyst who understands what a real exploitation attempt looks like in HTTP traffic can tell the difference between noise and an actual incident faster. A DevSecOps engineer building a CI/CD pipeline knows which security gates actually matter if they've seen how these vulnerabilities slip through in the first place. A cloud security professional evaluating an API gateway configuration benefits from understanding how the applications behind it can be attacked. Even GRC and audit professionals, who might never write an exploit themselves, produce far more useful risk assessments when they understand technically what a finding actually means rather than only what a scanner report labeled it.

I didn't fully appreciate that breadth when I started. I assumed web security was mainly relevant to penetration testers and maybe developers. The more labs I work through, the more I notice how often the same underlying concepts show up when I read incident reports, audit findings, or even casual conversations with people in completely different security roles.

Why solving the lab is only the beginning

Here's something I've had to actively correct in myself. It's very easy to treat each lab as a small puzzle to be solved and then closed. You get the payload working, the platform shows the green "solved" banner, and there's a genuine little hit of satisfaction in that moment. It's tempting to just move to the next one.

But solving a lab tells you that a particular technique works against a particular vulnerable pattern. It doesn't, by itself, tell you why the code was vulnerable in a structural sense, what the fix should actually look like in real source code, how a code reviewer would have caught it before it shipped, or what a reasonable organization should be doing at a process level to make sure this class of bug doesn't keep reappearing across their other applications. Knowing how to exploit an IDOR doesn't automatically make you good at explaining to a development team why their access control checks need to happen at the object level rather than just the endpoint level. Those are related skills, but they're not the same skill, and I think a lot of security education stops at the first one.

This is really the reason I started writing this series in the first place. I noticed that most walkthroughs, including plenty of good ones, focus almost entirely on the exploitation path — here's the vulnerable parameter, here's the payload, here's the flag. That's useful and I don't want to pretend otherwise. But it leaves out most of what actually determines whether a vulnerability gets fixed properly, gets missed by an audit, gets accepted as a risk the business can live with, or gets treated as a training gap that shows up again in six other applications built by the same team.

What I'm trying to do differently with this series

So for each lab I work through going forward, I'm trying to hold onto a fuller set of questions rather than stopping once the exploit works. What is actually happening at the HTTP request and response level, and what does that tell me about how the backend is processing input? What does the Burp Suite workflow look like for finding and confirming this specific vulnerability? What's the most likely root cause in the underlying code — not just "bad validation" as a vague label, but the actual structural mistake? What would a secure implementation look like, and where in the OWASP guidance or a relevant CWE entry does this vulnerability class map to? Where in the software development lifecycle should this have been caught, and by what checkpoint — a threat model, a code review, a static analysis rule, a pre-release security test?

Beyond that, I want to sit with the risk and governance side too. What's the actual business impact if this gets exploited in a real system, not a training lab? Is this the kind of finding that demands an immediate fix, or something that could reasonably be accepted temporarily with a compensating control while a proper remediation gets scheduled? What would an auditor actually want to see as evidence that an organization is managing this risk well? And what should security awareness training actually teach developers and other staff so the same mistake doesn't keep recurring?

That's a lot to hold onto for what starts as a single lab exercise, and I won't pretend I get all of it right every time. Some of this is genuinely new territory for me and I'm reasoning through it as I write rather than reciting something I've already mastered. But I think that honesty is part of what makes this useful, both to me and hopefully to anyone reading along. I'm not trying to present a polished expert's summary. I'm trying to build, piece by piece and in public, the kind of understanding that connects exploitation to prevention to detection to governance, because I think that's the understanding that actually matters once you're working in a real organization instead of a lab environment.

How I'd suggest a beginner approach the Academy

If you're just starting out, my honest suggestion is to resist the urge to jump straight into the exciting-sounding categories. SSRF and JWT attacks are genuinely interesting, but they'll make a lot more sense once the fundamentals are solid.

I'd start with the foundational material the Academy itself provides before touching any labs at all: how HTTP actually works, how cookies and sessions function, the basics of authentication versus authorization, the same-origin policy and why it exists, and general browser behavior. It's tempting to skip this because it feels like the "boring" part before the real hacking starts, but almost every vulnerability class you'll study later is really just a specific way one of these fundamentals breaks down. You'll also want a working knowledge of Burp Suite itself early on, since it's the tool you'll be living in for the rest of the journey — intercepting requests, modifying parameters, and watching responses change.

From there, I think it makes sense to move roughly in order of how commonly these vulnerabilities show up in real applications and how much they build on each other conceptually. SQL injection and cross-site scripting are a natural starting point, partly because they're common and partly because they force you to get comfortable reading and manipulating raw requests. Authentication and access control vulnerabilities come next naturally, since they build directly on the session and authorization fundamentals you'll have just covered. CSRF and SSRF follow well after that, and from there it opens up into the more specialized territory — XXE, file upload vulnerabilities, command injection, server-side template injection, NoSQL injection, and then further into JWT and OAuth issues, GraphQL-specific vulnerabilities, HTTP request smuggling, web cache poisoning, race conditions, and API security more broadly.

None of this needs to happen quickly. I've found that going slowly through the earlier categories and genuinely internalizing them makes the later, more complex categories click faster, because so much of the more advanced material is really just a recombination of the same underlying concepts in a new context.

Where this is heading

I don't think of this series as a finite project with a fixed endpoint so much as an ongoing record of actually learning this field properly rather than skimming it. Each article going forward will take a specific lab or vulnerability class and walk through it the way I've described here — the technical exploitation, yes, but also the root cause, the secure coding fix, the SSDLC checkpoint that should have caught it, the risk and audit perspective, and the practical controls that reduce it. Some of that will come easily to me. Some of it I'll clearly be working out in real time, and I'd rather that be visible than smoothed over.

If you're a student trying to build a foundation, a developer who wants to understand what security teams are actually looking for, a DevSecOps engineer trying to figure out which checks in your pipeline actually matter, an auditor who wants the technical grounding behind the findings you review, or just someone who's curious how a beginner's understanding of this field develops over time, I think there's something here for you. I'm not writing this as someone who has arrived. I'm writing it as someone still very much on the way, documenting the path as honestly as I can as I walk it.

If that sounds like something you'd want to follow, I'd genuinely like the company. There's a lot more ground to cover from here.