Introduction to Web Application Security
Learn where web applications lose trust, then practice each idea in the existing hands-on security labs.
Start here
Course introduction
Web security becomes less mysterious when you follow trust from a request to the system that interprets it. This course introduces five trust boundaries and connects each one to existing BLT University labs.
The lessons are intentionally short. Learn the reason behind a vulnerability, practice it safely, then return to the course to continue the path.
By the end of this course, you can
- Recognize where user-controlled input crosses an interpreter boundary.
- Explain how authentication, authorization, and session state differ.
- Use the existing practice labs to investigate common web security failures.
Learn, then practice
Course lessons
Work through these 5 lessons in order. Each lesson introduces one concept, then gives you a practical activity or lab to apply it.
Input crosses a boundary
Not startedUser input becomes dangerous when an interpreter mistakes data for instructions.
A search term, form field, or URL parameter starts as data. Trouble begins when an application joins that value directly into SQL, HTML, or another executable context.
The defensive question is simple: where will this value be interpreted next? Parameterized queries protect database structure. Context-aware output encoding prevents a browser from treating text as markup or script.
// Risky: input changes the query structure
db.query("SELECT * FROM users WHERE id = " + userId);
// Safer: the driver binds input as a value
db.query("SELECT * FROM users WHERE id = ?", [userId]);
Validation is useful, but it does not replace the safe API for the destination interpreter.
Put it into practice
Practice labs
Identity is not permission
Not startedKnowing who sent a request is different from checking whether that person may access the object.
Authentication establishes identity. Authorization decides what that identity can do. Applications often check the first and assume the second.
Every object lookup needs a server-side permission check. Hiding an identifier in the interface or changing it to a UUID does not enforce access control.
GET /api/invoices/842
Cookie: session=user-17
Required check: invoice 842 belongs to user 17
If the permission check happens only in the browser, a direct request can bypass it.
Put it into practice
Practice labs
The browser carries authority
Not startedCookies, redirects, and automatic requests can move trust somewhere the user did not intend.
A browser automatically attaches cookies to matching requests. Without an anti-forgery control, another page may cause an authenticated action on the learner’s behalf.
Redirect destinations also need boundaries. If any external URL is accepted, a trusted domain can become the first step in a phishing path.
The browser doing something automatically does not mean the user approved it.
Put it into practice
Practice labs
Server features reach further than expected
Not startedCommands and outbound requests can expose the operating system or internal network behind an ordinary feature.
Features such as diagnostics, image importers, and webhook testers often call powerful server-side APIs. If untrusted input controls a command string or destination URL, the feature may reach resources the user could never access directly.
Prefer structured process APIs, strict destination allowlists, and network controls that limit what the application can reach.
Put it into practice
Practice labs
Files and secrets outlive the request
Not startedUploaded files and exposed data remain risky after the original request has finished.
File names, extensions, and browser-provided content types are claims, not proof. Store uploads outside executable paths, generate server-side names, and validate the content you actually expect.
Secrets can also escape through logs, error messages, backups, and frontend bundles. Before shipping a response, ask whether every returned field belongs in the learner’s browser.
The safest secret in a frontend bundle is the one that was never placed there.
Put it into practice
Practice labs
Continue learning
Up next: Advanced Penetration Testing
Practice evidence-led reconnaissance, attack-path thinking, and clear reporting through a compact investigation.