Web Application Security: 9 Key Steps to Go from Zero to Operational

Web Application Security: The Essentials in One Article — Real Code, Diagrams and Concrete Steps, Excerpts from a 45-Lesson Course.

Web Application Security: 9 Key Steps to Go from Zero to Operational

Everyone can learn Web Application Security — provided they follow the steps in the right order. We have condensed a complete 45-lesson course into a clear path, with the most useful code snippets.

tl;dr
  • Introduction and Lab
  • OWASP Top 10 and Methodology
  • SQL NoSQL Command Injections
  • XSS Cross-Site Scripting
  • CSRF SSRF and Server-Side Request
~$ cat ./parcours.md # Web Application Security — 10 chapters
01
Introduction and Lab
→ Course presentation and web security ecosystem→ Install the lab: DVWA, Juice Shop, WebGoat+ 1 more lessons
02
OWASP Top 10 and Methodology
→ OWASP Top 10 explained (each category)→ Methodology: recon, mapping, attack, exploit+ 2 more lessons
03
SQL NoSQL Command Injections
→ Classic SQL injection (UNION, error-based)→ Blind SQLi: boolean-based and time-based+ 2 more lessons
04
XSS Cross-Site Scripting
→ Reflected, stored, DOM-based XSS→ Filter and WAF bypass (encodings, polyglots)+ 2 more lessons
05
CSRF SSRF and Server-Side Request
→ CSRF: token, SameSite, double-submit→ Basic SSRF and exploitation+ 2 more lessons
06
Authentication and Sessions
→ Intelligent brute force (Burp Intruder, Hydra)→ JWT: alg=none, cryptographic weaknesses, kid injection+ 2 more lessons
07
API Security REST and GraphQL
→ OWASP API Security Top 10→ BOLA and broken function level authorization+ 2 more lessons
08
Modern Vulnerabilities
→ Deserialization: PHP, Java, Python pickle→ Prototype pollution Node.js+ 2 more lessons
🏁
Final project (+ 2 chapters along the way)
→ You leave with a concrete and demonstrable project

Classic SQL injection (UNION, error-based)

NOTEObjective — Understand the mechanism of an SQL injection, detect it, then exploit it with the classic UNION-based and error-based techniques to extract data from a database.

Learning objectives

TIPAt the end of this module
  • Explain why an SQLi is possible
  • Detect an injection with a simple quote
  • Exploit a UNION-based injection to read other tables
  • Use error messages (error-based)
  • Understand the definitive fix: parameterized queries

Why does an SQL injection exist?

An SQLi occurs when user input is concatenated directly into an SQL query. The engine can no longer distinguish code (the query) from data (the input). The attacker then injects SQL that will be executed.

PayloadExpected behavior if vulnerable
'SQL error / 500
' OR '1'='1Authentication bypass
1' AND '1'='2Empty result (false condition)
1' AND '1'='1Normal result (true condition)

UNION-based: reading other tables

The UNION SELECT operator allows the results of a second query to be appended to the first. Requirements: same number of columns and compatible types. Start by determining the number of columns with ORDER BY.

OK Secure

WARNINGWarning: manually escaping quotes is NEVER enough (multiple bypasses exist). The only reliable defense is a parameterized query (prepared statement), where the engine separates code and data.

JWT: alg=none, cryptographic weaknesses, kid injection

NOTEObjective — Attack JSON Web Tokens: understand their structure, exploit classic flaws (alg=none, weak HS256 secret, RS256/HS256 confusion, injection via the kid header) and apply validation best practices.

Learning objectives

TIPAt the end of this module
  • Decode and understand the structure of a JWT
  • Exploit the alg=none flaw
  • Crack a weak HS256 secret
  • Understand the RS256/HS256 algorithm confusion
  • Exploit an injection via the kid header

JWT structure

A JWT consists of three base64url-encoded parts separated by dots: header, payload, signature. The header indicates the algorithm, the payload contains the claims (data), and the signature guarantees integrity.

AlgorithmSignatureVerification
HS256Shared secretSame secret
RS256Private keyPublic key
ConfusionPublic key as HS256Server incorrectly validates

Flaw 4: kid injection

The kid header (key ID) indicates which key to use. If used without sanitization to read a file or query a database, an attacker can inject a path (path traversal) or SQL.

Burp Suite Community: first steps

NOTEObjective — Get started with Burp Suite Community: configure the proxy, intercept HTTP/HTTPS traffic, install the CA certificate, and use the essential tabs (Proxy, Repeater, Target) to replay and modify requests.

Learning objectives

TIPAt the end of this module
  • Configure the browser to use the Burp proxy
  • Install the CA certificate to intercept HTTPS
  • Intercept, modify and forward a request
  • Replay a request in Repeater
  • Navigate the sitemap (Target tab)

What is Burp Suite?

Burp Suite is an interception proxy placed between your browser and the web server. All traffic passes through it: you can view it, modify it on the fly and replay it. It is the central tool for every web pentester. The Community edition is free and more than sufficient for learning.

Repeater

Replay a request as many times as you want while modifying it.

Target

Builds the mapping (sitemap) of the visited application.

Configuring the proxy

By default, Burp listens on 127.0.0.1:8080. You must tell the browser to send its traffic there. The simplest method is Burp’s built-in browser (“Open Browser”), which is preconfigured. Otherwise, configure a manual proxy or use the FoxyProxy extension.

Manual proxy (Firefox)

WARNINGWarning: this certificate is specific to YOUR Burp installation. Never install it on someone else’s machine and remove it when you are done: it allows decryption of your HTTPS traffic.

First workflow: intercept and replay

Here is the basic action you will repeat thousands of times.

StepAction
1Proxy tab → Intercept “on”
2Navigate to the target (e.g. DVWA login)
3The request is captured — read it, modify it
4Right-click → “Send to Repeater”
5In Repeater, change a parameter, click “Send”

Example: modifying a parameter in Repeater

go-further

This article covers the most useful snippets — the complete Web Application Security course (11 chapters, 45 lessons, corrected exercises and final project) takes you all the way.

./access-the-full-course free course: Mastering Claude Code

FAQ

How long does it take to learn Web Application Security?
With a structured progression (11 chapters, 45 short and practical lessons), you reach an operational level in a few weeks at 30 to 60 minutes per day. The key is to practice each concept immediately.
Are there any prerequisites?
Basic computer knowledge is enough. If you can use a terminal and read simple code, you are ready.
Where to start concretely?
Reproduce the commands in this article, then follow the complete Web Application Security course: it chains the 45 lessons in order, with exercises and a final project.

📬 Want to receive this type of guide every week? Subscribe for free — real code, zero fluff.