The Exploit HQ

Web Application Security for Beginners · lesson 0 · 2026-09-05 · updated 2026-10-12

Web Application Security for Beginners — Start Here

Before you start

Welcome to The Exploit HQ, and welcome to the Web Application Security course. Every app on the internet has an attack surface, and this course teaches you exactly what that means — with live demonstrations against a real, deliberately-vulnerable web app. If you have never run a security test in your life, you are in exactly the right place.

Let me start with who this course is built for.

Who this course is for

This is built for people who have never done a security test before. No background in cyber security required, no degree, nothing assumed. If you are a developer who wants to understand what attackers look for in your code, this is the right place. If you have simply always wondered how websites actually get compromised, this is the right place. Every single technique in this course is demonstrated live against a real running application, not just described on a slide.

Here is what the course covers, in order.

4 lessons · the OWASP Top 10 patterns

Four lessons, each covering one of the patterns that appear in the O-WASP Top Ten — the list of the most common and most dangerous web application risks. Broken access control, where the app lets you read or modify things that belong to someone else. File inclusion and path traversal, where you trick the server into reading files it should never expose. Information disclosure, where developers left credentials and config sitting in backup files or response headers. And parameter tampering, where the app trusted a number sent from the browser and you simply changed it. These are not exotic theoretical attacks. They are the things that show up in real breach reports every week.

Why does web application security matter at this level?

Why web app security?

Most software that exists today is a web application, or depends heavily on web services. Broken access control alone sits at number one on the O-WASP Top Ten, every single year, because it is genuinely that common. A single misconfigured URL parameter, a backup file left on a public directory, a response header that reveals the framework version — these are the kinds of findings that show up in real penetration tests and real breach investigations. Learning to recognize them is valuable whether you are building applications, testing them, or just trying to understand how the digital world works.

Here is what you need to follow along.

What you need

A computer. The demos in this course run on Linux, and they work on Mac and on Windows via WSL. The practice applications — DVWA and Juice Shop — are free, open source, and run entirely on your own machine. Nothing goes to the internet. Curl is already installed on Linux and Mac. And permission, which is the one item on that list we are going to come back to in a moment.

Let me show you exactly the kind of thing this course demonstrates.

What a real web vulnerability looks like

curl -s -b lab/cookies.txt "http://127.0.0.1:8080/vulnerabilities/fi/?page=/etc/passwd" | grep -oP "root:[^<]+"
Part What it does
?page=/etc/passwd a URL parameter meant to load page templates — pointed at a system file
grep -oP "root:[^<]+" pull the passwd entry from the HTML response

This is a file inclusion vulnerability — Part Two of the course. The application has a URL parameter called page that is supposed to load different sections of the site. But the developer never validated what value that parameter could hold. So instead of loading a page template, we point it at the server’s own password file. The command sends the request. The grep pulls out what came back. Let’s run it.

The server’s own password file, read through a URL parameter. That is a real file inclusion vulnerability running against a local practice application — deliberately built for this kind of learning. That is the level of demonstration you get in every lesson of this course. Not a diagram. Not a description. The actual technique, explained step by step.

Now the rule that matters more than any technique in this course.

Only test what you’re allowed to test

Only ever test a web application you own, or one where you have clear, written permission to test. Running these techniques against a site you do not have permission to test is a computer crime in most jurisdictions — it does not matter that the technique itself is simple or that you did not cause damage. The practice applications in this course exist so that you can learn all of this safely and legally, on your own machine, with no risk of crossing that line.

That is everything you need to know before you start.

Ready to begin?

Go straight to Part One — Broken Access Control and IDOR — and work through the parts in order, because each one builds on the concepts from the previous lesson. All four parts are in the playlist linked in the description and pinned in the comments. Take your time with the demonstrations, run the commands yourself, and see what comes back. The people who get the most out of this are the ones who actually type along. Thanks for learning with The Exploit HQ. Open that terminal, and I will see you in Part One.