Web Application Security

Most of the world's data now lives behind websites and web apps, so that's where most attacks aim. This lesson teaches how web apps break — using the industry-standard OWASP Top 10 — and how to test safely on a practice app built for the purpose.

Practise on DVWA, nothing else We use DVWA (Damn Vulnerable Web Application), a website designed to be hacked for training, running inside your own lab. Testing these techniques on any website you don't own or aren't authorised to test is a crime. Keep it in the lab.

How a web app works (the 30-second version)

Your browser (the client) sends an HTTP request; a web server runs code that often talks to a database, then sends back a page. Attacks abuse the trust between these three parts — usually by sneaking input that the app treats as instructions.

Analogy — A waiter taking an order You (the browser) tell a waiter (the server) your order, and they fetch it from the kitchen (the database). Attacks happen when a customer writes something sneaky on the order slip — like “bring food AND open the safe” — and a careless waiter obeys the extra instruction. Good security means the waiter treats the whole slip as an order, never as commands.

The OWASP Top 10 (the field's most important list)

OWASP (Open Worldwide Application Security Project) publishes the ten most critical web risks. Every web security professional knows this list.

#	Risk	In plain words
A01	Broken Access Control	Users reaching things they shouldn't
A02	Cryptographic Failures	Weak or missing encryption of sensitive data
A03	Injection	Input treated as commands (SQLi, etc.)
A04	Insecure Design	Flaws baked in from the start
A05	Security Misconfiguration	Default passwords, exposed settings
A06	Vulnerable Components	Old libraries with known CVEs
A07	Auth Failures	Weak login/session handling
A08	Data Integrity Failures	Trusting unverified updates/data
A09	Logging & Monitoring Failures	Not noticing attacks
A10	Server-Side Request Forgery	Tricking the server into making requests

Deep dive 1 — SQL Injection (A03)

A database is queried with SQL. If an app pastes your input straight into a query, you can change what the query means. The classic teaching example in a login box:

# The app builds: SELECT * FROM users WHERE name='INPUT'; # A tester types this classic string into the username field on DVWA: ' OR '1'='1 # The query becomes ... WHERE name='' OR '1'='1' — always true — bypassing the check.

Why it works: the app failed to separate data from code. The fix (which you should learn as a builder too): parameterised queries / prepared statements, which force input to stay data. You can automate discovery of these flaws in the lab with sqlmap -u "http://192.168.56.101/vuln?id=1" against DVWA.

Deep dive 2 — Cross-Site Scripting / XSS (part of A03)

XSS is injecting into a page instead of a database: if an app echoes your input back without cleaning it, your input can include a script that runs in other visitors' browsers. The universal harmless test string:

The fix: output encoding (turn < into < so it displays as text) and a Content-Security-Policy. As a developer, never trust input; escape on output.

Tool deep dive: Burp Suite

Burp Suite (bundled with Kali) sits between your browser and the web app as a proxy, letting you pause, read, and modify every request — the essential web-testing tool.

Proxy — intercept and edit requests before they reach the server.
Repeater — resend a request with tweaks to see how the app responds.
Intruder — automate systematic input testing (in the lab).

$ burpsuite & # launch, then set your browser proxy to 127.0.0.1:8080

Try It Yourself (simulated DVWA responses)

Type a test payload to see the concept: ' OR '1'='1 or <script>alert(1)</script>.

DVWA (lab) — practice input

Simulated vulnerable app (lab only). Enter a classic test payload.

input>

Practical Exercise 9.1 — Break and then fix a login (DVWA)

Install DVWA in your lab (a Docker image or the Metasploitable web app), set difficulty to “Low.”
On the SQL Injection page, submit ' OR '1'='1 and observe the bypass.
Switch DVWA difficulty to “High” and try again.
Result: it fails — because the high-security version uses parameterised queries. You've now seen the fix work.
Repeat with the XSS page and the <script> payload, then read how the secure version escapes output. Write one sentence each on the cause and the fix.

Quick check: What is the correct fix for SQL injection?

Hide the login page

Use parameterised queries so input can't become code

Use a longer database password

Block the letter O

Parameterised queries (prepared statements) keep user input as data, so it can never be executed as SQL.

Why does this matter for your career? Web app security (AppSec) is a huge, well-paid specialism. The OWASP Top 10 is referenced in nearly every security job and audit. Burp Suite is the web-testing tool, and these skills sit at the heart of CEH, the OSCP, and web-focused bug-bounty work.

Key takeaways

Web attacks usually make an app treat input as instructions.
The OWASP Top 10 is the field's shared checklist — know it.
SQLi → fix with parameterised queries; XSS → fix with output encoding.
Burp Suite intercepts and edits requests; practise only on DVWA.