03 — Web Application Security
Master the foundations of web application security through interactive lessons, real-world labs, and practical exercises. Learn to analyze web traffic, test applications with professional security tools, identify common vulnerabilities, and apply effective defenses used throughout the cybersecurity industry.
Introduction To Web Application Security
Welcome to the front lines, Cyber Defender. This section lays the groundwork for everything you will build, analyze, test, and defend throughout this course.
When most people think of cybersecurity, they picture firewalls blocking suspicious IP addresses or antivirus software scanning a laptop for malware. That is network and endpoint security.
Web Application Security, also called AppSec, is different. It focuses on protecting software applications that run over the internet, especially the application layer where users, requests, sessions, business logic, and databases interact.
💡 AppSec Definition:
Web application security protects websites, login pages, dashboards, APIs, cookies, sessions, databases, admin panels, and user accounts from unauthorized manipulation, theft, or abuse.
Why Web Applications Matter
Web apps are the central nervous system of modern business. They handle online banking, medical records, corporate portals, school dashboards, shopping carts, government services, and cloud infrastructure control panels.
Because web applications must be accessible to real users around the world, they usually cannot be hidden completely inside a private network. They are exposed to the public internet, which makes them a major target for attackers.
A single weakness in a login form, password reset page, file upload feature, admin panel, or API endpoint can lead to stolen accounts, leaked data, changed records, fraud, or full system compromise.
The Architecture Baseline
A web application is not just a static page you look at. It is a live system made of moving parts. To defend a web application, you need to understand how data travels through the browser, the request, the server, and the database.
The browser is the frontend. It displays HTML, CSS, and JavaScript. It is what the user sees and interacts with.
When a user clicks, logs in, searches, or submits a form, the browser sends an HTTP request with headers, cookies, parameters, and data.
The server receives the request and checks identity, permissions, business logic, and whether the submitted data is safe.
The database stores valuable information such as accounts, passwords, records, transactions, messages, and logs.
Golden Rule:
Never fully trust the frontend. JavaScript runs on the user's device, so an attacker can modify browser code, bypass form validation, change hidden fields, and edit requests before they reach the server.
Developing The Security Mindset
To be an effective defender, you must learn to think like an ethical hacker. This means switching from a functional mindset to an adversarial mindset.
Functional mindset:
“I built a search bar. When a user types a keyword and clicks search, the application displays matching articles from the database.”
Security mindset:
“What happens if the user does not type a normal keyword? What if they type database commands, scripts, unexpected characters, or a very long input?”
Attackers do not only look at what a feature is supposed to do. They look for ways to abuse how the feature works underneath.
Cyber Defender: Protect The Portal
The corporate portal is under active attack. You are the lead Cyber Defender. Malicious packets are moving from the public Internet toward the Database Vault.
Your job is to choose the correct defense before the threat reaches the database.
Your Defensive Arsenal:
Input Validation: Stops dangerous user input before it reaches the database.
Session Lock: Protects against stolen cookies and hijacked sessions.
Permission Check: Verifies whether a user is actually allowed to access something.
WAF Blast: Blocks suspicious web traffic at the perimeter.
Public Internet
Web App Gate
Database Vault
Section 1 Assessment
Answer the quiz questions and complete the matching activity. Since this course has 13 sections, completing Section 1 will update the main progress bar to 8%.
Multiple Choice
1. What is the fundamental scope of Web Application Security?
2. Why is it a flaw to rely only on frontend JavaScript validation?
3. What does Broken Access Control mean?
Matching Activity
Instructions: Match each attack or weakness to the best defense. Each dropdown has four options, but only one is the best match.
How The Web Works
Before you can test or defend a web application, you need to understand how browsers and servers communicate.
Every time a user visits a website, clicks a button, logs in, submits a form, or opens a dashboard, the browser sends an HTTP request. The server receives that request, processes it, and returns an HTTP response.
Web security analysts study this traffic because many attacks are hidden inside requests and responses. A weak application may trust a parameter too much, expose sensitive headers, send insecure cookies, leak errors, or return private data to the wrong user.
Main idea:
The web is a conversation. The browser asks for something, and the server answers. Security comes from understanding exactly what is being asked, what is being returned, and whether the application should trust it.
The Request And Response Model
The web runs on a request and response model. The client, usually a browser, asks for something. The server decides how to respond.
The user opens a page, clicks a link, submits a form, or sends data through the interface.
The request contains a method, path, headers, cookies, and sometimes a body.
The server routes the request, checks logic, talks to databases or APIs, and prepares a response.
The response returns a status code, headers, cookies, and content such as HTML or JSON.
HTTP vs HTTPS
HTTP is the protocol used to transfer web data. HTTPS is HTTP protected by TLS encryption.
Without HTTPS, someone on the network may be able to read or modify traffic. With HTTPS, traffic is encrypted between the browser and server, making usernames, passwords, cookies, and private data much harder to steal in transit.
Traffic is not encrypted. Data can be exposed if someone can observe the network path.
Traffic is encrypted using TLS. This protects confidentiality and integrity in transit.
Login cookies should be sent over HTTPS and marked Secure.
Analysts check whether sensitive pages force HTTPS.
Important:
HTTPS does not automatically make a website secure. A site can use HTTPS and still have SQL injection, XSS, broken access control, weak sessions, or vulnerable plugins.
HTTP Methods
HTTP methods describe the action the client wants to perform. Security analysts pay attention to methods because viewing a page is different from submitting a password, updating an account, or deleting a record.
Usually requests data or opens a page. Example: viewing a product page.
Usually submits data. Example: sending a login form.
Often updates or replaces data in APIs.
Often requests deletion of a resource in APIs.
Status Codes
Status codes tell the browser what happened. They help security analysts understand whether a request worked, failed, was blocked, redirected, or caused a server error.
The request worked.
The user is being sent somewhere else.
Authentication is required or failed.
The server understood the request but refused it.
The requested resource was not found.
The server had an internal problem.
Status codes are clues. If a normal user gets 403 on an admin page, that may show access control is working. If the same user gets 200 and can view admin data, that may be a serious issue.
Headers And Cookies
Headers carry extra information about a request or response. They can describe the content type, browser type, accepted formats, cache behavior, authorization tokens, cookies, redirects, and security controls.
Tells the browser what kind of data is being returned.
Creates or updates a cookie in the browser.
May carry tokens for API access.
Help reduce browser-based risks.
Request Method Inspector
Click each method to inspect how a security analyst thinks about it.
Section 2 Assessment
Complete the quiz and matching activity. Since this course has 13 sections, completing Section 2 updates the main progress bar to 15%.
Multiple Choice
1. What does HTTPS add to HTTP?
2. Which HTTP status code usually means the request was successful?
3. What are HTTP headers used for?
Matching Activity
Instructions: Match each web concept to the best description.
Cookies, Sessions, and Authentication
Cookies, sessions, and authentication are the systems that help a web application remember users and control access. Without them, a website would treat every request like it came from a brand-new visitor.
When you log in to a website, the server needs a way to recognize you on the next page. It would be annoying and unsafe to send your password on every single request. Instead, web apps commonly create a session and give the browser a cookie that points to that session.
This section teaches how login systems work, why cookies matter, what session IDs do, and how authentication is different from authorization. These concepts are extremely important because weak session handling can lead to account takeover, data exposure, or unauthorized access.
How Login Systems Usually Work
A login form normally asks for something like a username and password. The browser sends those values to the server. The server checks whether the credentials are valid. If they are valid, the server creates a session and sends back a cookie.
On later requests, the browser automatically sends that cookie back to the server. The server uses it to find the user’s session and decide whether the user is logged in.
A session cookie is like a temporary visitor badge. The password proves who you are at login, but the session cookie helps the website remember you after that.
What Cookies Are
A cookie is a small piece of data stored by the browser for a specific website. Cookies can store preferences, tracking IDs, language settings, and session identifiers.
In security, the most important cookies are often session cookies. A session cookie can act like proof that the browser already logged in. If an attacker steals or abuses a valid session cookie, they may be able to act like the logged-in user.
HttpOnly, Secure, and SameSite
Cookie flags are settings that tell the browser how to protect a cookie. These flags do not fix every security issue, but they reduce common risks.
For login sessions, a strong setup usually includes HTTPS, Secure cookies, HttpOnly cookies, careful SameSite settings, strong session randomness, session expiration, and server-side permission checks.
Two Concepts Beginners Often Mix Up
Authentication and authorization sound similar, but they are different. Authentication asks, “Who are you?” Authorization asks, “What are you allowed to do?”
What Can Go Wrong?
Session systems are sensitive because they control identity. If a web app handles sessions poorly, attackers may be able to stay logged in too long, reuse old tokens, access accounts they should not, or take advantage of weak cookie protection.
Cookie Inspector Lab
Click each cookie part to understand what it does. This is the type of information you may inspect in browser Developer Tools or a proxy during authorized testing.
Section 3 Quiz
Answer all 3 questions. Each question has 4 choices. When you get all answers correct, Section 3 is complete.
What does authentication check?
What does authorization check?
Why is HttpOnly useful for session cookies?
Web Application Architecture
Understanding how enterprise systems connect is what separates a beginner from a strong application security learner. Real AppSec and penetration testing work requires more than knowing vulnerability names. You need to understand where the frontend, backend, APIs, microservices, and databases connect.
In interviews, candidates may be asked questions like: “If you compromise this frontend component, how could you pivot to the backend microservices?” This section helps you understand those paths safely from a defender’s point of view.
Section goal:
Learn how modern web applications are built, where trust boundaries exist, and where hidden attack paths can appear.
The Modern Frontend And Client-Side Risk
Older websites often sent simple static HTML pages to the browser. Modern enterprise frontends are different. They are full software applications running inside the user’s browser, often built with frameworks like React, Angular, or Vue.
In a modern frontend architecture, the user requests the site, the server sends a small HTML file plus a large JavaScript bundle, and the browser executes that JavaScript to build the interface and fetch data in the background.
Compiled frontend code sent to the browser. Attackers can inspect it, search it, and study how the app works.
Helpful for debugging, but risky if exposed in production because they can reveal readable source code.
API keys, tokens, passwords, or internal notes should never be placed inside frontend code.
Frontend checks are useful for user experience, but they must not be trusted for real authorization.
Security rule:
The browser is controlled by the user. Anything enforced only in the browser can be changed, bypassed, or inspected.
Backend Monoliths vs Microservices
When the frontend needs to save a file, process a payment, or authenticate a user, it sends data to the backend. Enterprise systems usually organize backend logic in one of two major patterns: monoliths or microservices.
Monolithic Architecture
A monolith means the entire application is built as one large codebase. Routing, authentication, billing, image processing, business logic, and database connections may all live inside one unified backend system.
Main risk:
The blast radius can be large. If one feature is compromised, the attacker may gain access to other sensitive parts of the same backend environment.
Microservices Architecture
Microservices split the application into many smaller services. Each service has a specific job, such as authentication, payments, billing, notifications, inventory, or user profiles.
Perimeter fallacy:
Developers may assume internal microservices are safe just because they sit behind an API Gateway. Strong systems still require authentication, authorization, logging, and validation between internal services.
The API Gateway
The API Gateway is often the single public entry point into a microservices environment. It receives external requests from the frontend and routes them to the correct backend services.
Sends requests to the correct internal service.
Checks whether the request has a valid identity token.
Slows or blocks abusive traffic patterns.
Can inspect requests for suspicious patterns before forwarding them.
Database Layers And Isolation Strategy
The deepest layer of the architecture is persistent storage. Enterprise apps often separate data based on structure, sensitivity, speed, and business purpose.
| Database Type | Common Technology | Best Used For | Primary Security Focus |
|---|---|---|---|
| Relational SQL | MySQL, PostgreSQL | Structured critical tables like users, orders, and ledgers. | Prevent SQL injection and isolate database permissions. |
| NoSQL | MongoDB, DynamoDB | User profiles, activity feeds, flexible documents, and rapid data models. | Prevent object injection and loose access control rules. |
| In-Memory Cache | Redis, Memcached | Fast temporary data such as active sessions and queues. | Restrict unauthorized network access because caches may hold sensitive session data. |
Data Flow Attack Path Simulator
Select an architecture choice to see how it changes the risk picture. This helps you understand how architecture affects blast radius and defense strategy.
Cyber Defender: Perimeter Breach
An engineer accidentally committed live cloud credentials into a public client-side bundle during an emergency deployment. A scraper bot found the source map folder and extracted the credential.
Your job is to choose the action that fully neutralizes the incident.
Emergency action call:
Which response actually stops the threat instead of only hiding the evidence?
Section 4 Assessment
Complete the quiz and matching activity. Since this course has 13 sections, completing Section 4 updates the main progress bar to 30%.
Multiple Choice
1. Why are client-side validations not enough during a professional security assessment?
2. What risk appears when microservices do not authenticate each other?
3. What security role does an API Gateway play?
Matching Activity
Instructions: Match each architecture concept to the best security meaning. The dropdowns are wider here so they should not cut off.
Browser DevTools
for Security
In this section you step into the browser like a real web security analyst. DevTools lets you inspect the page, watch network traffic, read cookies, test JavaScript behavior, and understand what the application is actually doing under the surface.
Most beginners only see the website. A defender sees the hidden conversation between the browser, server, APIs, cookies, and database-backed features.
Learn how to use DevTools to investigate web applications safely — inspect requests, understand frontend behavior, and identify where sensitive data may be exposed.
The Browser Is Your First Security Lab
Every modern browser includes built-in developer tools. These tools are not only for developers. Security analysts use them to understand how the application loads, what scripts run, what requests are sent, what cookies exist, and what data comes back from APIs.
DevTools matters because many web security clues are visible before you ever reach advanced tools like Burp Suite or OWASP ZAP.
Inspect HTML structure, hidden fields, buttons, and forms. Nothing is truly hidden here.
Watch every request, response, API call, status code, header, and payload in real time.
View cookies, local storage, session storage, tokens, and cached data.
Read errors, test JavaScript, and uncover frontend logic and debug leaks.
How DevTools Sees the Full Request Lifecycle
The browser is not just displaying a page — it's receiving code, running scripts, sending API requests, storing cookies, and rendering server responses. DevTools gives you a window into all of it.
DevTools Investigation Console
You've landed on a suspicious portal. Click each DevTools tab below to investigate. Watch the threat meter shift as you uncover clues.
Section 5 Assessment
Complete the quiz and matching activity. Finishing Section 5 updates your course progress to 38%.
Multiple Choice
Matching Activity
Match each DevTools area to what a security analyst would inspect there.
OWASP ZAP Fundamentals
In this section you step away from the passive client environment and deploy an open-source, enterprise-grade interception proxy: OWASP ZAP (Zed Attack Proxy). This module teaches you how to sit directly in the middle of the traffic lane between the browser and the server.
Understand interception proxy architecture, install ZAP's CA certificate to handle HTTPS, and run your first passive scan and spider to map an application's hidden attack surface.
The Interception Proxy Architecture
When you open a website normally, your browser talks directly to the server. ZAP breaks that direct line — it becomes a local gateway that catches every packet mid-flight, holds it, lets you read or modify it, then releases it. This is a Man-in-the-Middle (MITM) architecture used for defensive analysis.
The CA Certificate Obstacle
HTTPS encrypts traffic so proxies cannot read it by default. ZAP solves this by generating its own local Root CA. When you install that certificate into your browser, ZAP can decrypt, inspect, and re-encrypt your local SSL/TLS streams — all within your own machine for authorised testing only.
ZAP's CA certificate should only be installed in a dedicated testing browser profile, never your personal daily-use browser. Remove it when testing is complete.
Automated Mapping — Spidering and Site Trees
Once ZAP is in the traffic lane it can automatically build a complete map of everything an application exposes. Two scanning modes give you different levels of depth.
ZAP watches traffic in the background and builds an inventory of headers, missing security flags, and exposed metadata without sending a single aggressive packet.
Crawls HTML links across static pages to discover routes and endpoints. Fast but misses anything rendered by JavaScript.
Uses a headless browser to click interactive React and Angular elements, uncovering hidden API endpoints the standard spider would never find.
| Spider Type | How It Works | Best For | Limitation |
|---|---|---|---|
| Standard Spider | Follows HTML anchor links | Static multi-page sites | Misses JS-rendered content |
| AJAX Spider | Headless browser clicks buttons | React / Angular / Vue apps | Slower, resource-heavy |
| Passive Scan | Analyses existing traffic | Safe, non-intrusive recon | Only sees traffic you browse |
Setting Up the Trap
Configure the port mappings below to correctly line up your proxy gateway before running the first automated spider. ZAP listens on a local port — your browser must point to the same port for traffic to flow through it.
Cyber Defender: The Invisible Net
An unmapped API endpoint is leaking corporate architecture diagrams but is completely invisible on the main website links. Choose the right ZAP technique to map the invisible infrastructure before a threat actor finds it.
Choose your tooling maneuver:
Section 6 Assessment
Complete the quiz and matching activity. Finishing Section 6 updates your progress to 46%.
Multiple Choice
Matching Activity
Match each ZAP concept to its correct definition.
Burp Suite Fundamentals
If OWASP ZAP is your defensive Swiss Army knife, Burp Suite is your tactical sniper rifle. Used by over 90% of professional application security engineers and penetration testers, mastering this tool is a non-negotiable prerequisite for landing a job in AppSec.
Learn the Intercept and Modify workflow, master surgical request tampering with Repeater, and understand how Intruder automates fuzzing attacks across multiple payload positions.
The Intercept & Modify Workflow
The core function of the Burp Proxy is simple: it sits silently between your browser and the remote server. When Intercept is ON, Burp catches outgoing HTTP requests and holds them mid-air.
submits form
intercepts · holds
modifies request
receives modified
Why We Intercept
When you submit a form on a website, the browser immediately ships that data out. Burp changes that. With the request paused in Burp's Proxy Tab, you can manually rewrite parameters, inject unexpected characters, delete headers, or modify cookies before hitting Forward to release the packet.
Surgical Tampering with Repeater
Resubmitting forms through a browser to test a flaw is tedious and alerts security systems with messy client-side overhead. Instead we use Burp Repeater (Ctrl+R).
The Sandbox Workflow
- Capture a request in your Proxy history.
- Right-click and select Send to Repeater.
- Inside Repeater, edit the raw text of the request as many times as you want and click Send.
- Instantly see the server's raw response in the right-hand pane.
Repeater lets you test hypotheses rapidly: "What happens if I change this parameter to a negative number? What if I send a string that is 10,000 characters long?" No browser overhead, no noise.
Automated Fuzzing with Intruder
Fuzzing sends hundreds of unexpected inputs into an application field to see if it breaks. Doing this manually in Repeater would take hours. Burp Intruder automates it.
You highlight a specific value in a request and mark it as a Payload Position. You then feed Intruder a list of test values.
The Four Primary Attack Types
Targets one single payload position at a time. Best for single-field brute-forcing like a login password field.
Places the exact same payload into multiple marked positions simultaneously.
Uses multiple payload lists simultaneously — line 1 from list A with line 1 from list B, injected into separate positions.
Tests every possible combination. 100 usernames × 100 passwords = all 10,000 combinations tested.
The Precision Repeater Lab
Analyze the captured HTTP request below. Modify the role parameter to simulate how an analyst isolates horizontal privilege escalation. Edit the fields and click Send to see the server response change.
Cyber Defender: The Intruder Strike
An attacker is brute-forcing a corporate login portal. They have captured a single request token and are loading a dictionary of 5,000 passwords against the admin account. You must identify the correct Intruder attack type to analyse their strategy.
Choose your defence / analysis action:
Section 7 Assessment
Complete the quiz and matching activity. Finishing Section 7 updates your progress to 54%.
Multiple Choice
Matching Activity
Match each Burp Suite tool to its correct function.
Encoding & Cryptography Basics
Before we look at SQL Injection or Cross-Site Scripting, we must understand how computers translate data across different protocols. In AppSec, a failure to understand the difference between encoding and encryption can cause catastrophic security assumptions.
Distinguish between encoding, hashing, and encryption. Recognise Base64 and URL encoding on sight. Understand why password salting defeats rainbow table attacks.
Encoding vs. Hashing vs. Encryption
Let's bust the single biggest myth in beginner cybersecurity right now: Encoding is NOT security.
Converts data from one readable format to another using a publicly known, reversible algorithm. Its goal is usability, not confidentiality.
Takes any input and transforms it into a fixed-length string. Strictly one-way — you can never reverse a proper hash, only compare them.
Scrambles data to keep it hidden. Requires a secret key to lock and unlock. Without the key, ciphertext looks like pure random noise.
Common Web Encodings
Web applications use different encodings depending on where data is being sent. As an AppSec professional, you must learn to recognise them on sight.
| Encoding Type | What It Does | Example | Security Role |
|---|---|---|---|
| URL Encoding | Replaces unsafe characters with % + hex | space → %20, & → %26 | Safe URL transmission |
| Base64 | Encodes binary data as ASCII text | admin → YWRtaW4= | Transport only — NOT security |
| HTML Encoding | Replaces symbols with HTML entities | < → <, > → > | Primary XSS defence |
HTML encoding is your primary defence against Cross-Site Scripting (XSS). The character < becomes < — the browser prints a literal symbol instead of starting a new HTML tag.
Secure Password Storage — Salting & Hashing
If an attacker breaches a database vault, they should never find passwords sitting in plaintext. Modern systems use salted hashing to prevent this.
Why Hashing Alone Is Weak
If two users share the password Password123, they produce identical hashes. Attackers use precomputed Rainbow Tables of billions of known hashes to look up the plaintext instantly.
The Fix — Salting
Before hashing, the application generates a long, unique, random string called a Salt and appends it to the password. Even if two users share the same password, their unique salts produce completely different hashes in the database — making rainbow table attacks impossible.
The Decoder Sandbox
Decode the obfuscated parameter below to reveal the identity token and intercept the data context. Select an encoding type, paste or edit the input, and hit Decode.
Section 7 & 8 Combined Assessment
Score a perfect 3/3 to lock in Section 8 completion and update progress to 61%.
Multiple Choice
cnVubmluZz10cnVl. What type of format is this, and is it secure?Matching Activity
Match each concept to its correct definition.
SQL Fundamentals
Welcome to Section 9. To hack or defend database-driven web applications, you must first speak fluent SQL, which stands for Structured Query Language. In this section, you will learn how databases organize data, how they establish complex relationships, and how to query them like an elite database administrator or security engineer.
Understand relational databases, primary keys, foreign keys, SQL sublanguages, SELECT queries, and the UNION operator before moving into SQL Injection.
Relational Databases, Tables, & Schemas
A Relational Database Management System stores data in structured tables that can be linked based on data common to each. Think of a database as a collection of high-powered, interconnected spreadsheets.
Core Terminology: Interview Prep
The full container hosting an application's datasets, such as prod_ecom_db.
A structured grid containing columns and rows, such as the users table.
A vertical set of data values of a specific type, such as email VARCHAR(255).
A single horizontal entry containing unique data for each column, such as a user profile.
The blueprint defining tables, columns, data types, and strict interaction rules.
Keys to the Kingdom
In an RDBMS, data integrity is maintained using special attributes called keys. Understanding keys is critical for security because they establish the paths that SQL injection attacks may attempt to traverse to extract unauthorized records.
Primary Keys
A Primary Key is a column, or combination of columns, that uniquely identifies every single row in a table.
The Rules: A Primary Key must be completely unique, and it can never contain a NULL value.
Example: In the users table, the user id acts as the Primary Key.
Foreign Keys
A Foreign Key is a column in one table that points directly to the Primary Key of another table.
The Rules: It enforces referential integrity so records cannot point to users or objects that do not exist.
Example: The orders table uses user_id to reference the users table.
The Four SQL Sublanguages
SQL is divided into four distinct sublanguages, each designed for a specific database management task. Security engineers inspect which of these sublanguages a web application's database connection is allowed to execute.
DML
Data Manipulation Language manages data inside existing tables.
Security Target: Attackers use DML to extract, corrupt, or wipe records.
DDL
Data Definition Language modifies the physical schema itself.
Security Target: High privilege attackers may destroy tables or change structures.
DCL
Data Control Language manages administrative permissions and security rights.
Best Practice: Web apps should use low-privilege service accounts.
TCL
Transaction Control Language keeps multi-step database operations consistent.
Example: A failed bank transfer can trigger a rollback.
Writing Basic SQL Queries
Before you can manipulate SQL queries, you must master writing them cleanly. The primary SELECT statement tells the database which columns to return, which table to inspect, and which condition must match.
Example 1: Fetching Specific Data
This instructs the database engine to open the users table, filter for the record where the id is exactly 3, and return only the username and password hash columns.
The UNION Operator: Critical for Section 10
The UNION operator combines the result set of two or more SELECT statements into one output table.
Each SELECT statement must have the exact same number of columns, and the columns must have compatible data types in the same order.
The SQL Query Terminal
You are logged into an administrative database terminal. Write and execute SQL queries to retrieve sensitive keys, filter inventory tables, and practice syntax mechanics.
Cyber Defender: Relational Breach
An active database session has been hijacked. You are the Database Administrator. An attacker is attempting to execute commands on your relational engine.
Choose your defence / analysis action:
Section 9 Assessment
Passing requirement: Achieve 100% to unlock Section 10, SQL Injection.
Why These Answers Matter
A Primary Key must uniquely identify every row and must never be NULL. That is how the database keeps records stable and searchable.
CREATE, ALTER, DROP, and TRUNCATE change the structure of the database. That makes them Data Definition Language commands.
If a web app uses root or sa credentials, a SQL injection flaw becomes much more dangerous because the attacker may inherit administrator-level database permissions.
SQL Injection
This is the turning point of your offensive and defensive education. SQL Injection is one of the most devastating vulnerability classes in web application history. In this section, you will learn how unsafe query construction collapses the boundary between code and data.
Identify SQLi patterns, understand authentication bypass logic, map UNION extraction constraints, recognize blind SQLi behavior, and remediate the flaw with parameterized queries.
What Is SQL Injection?
SQL Injection occurs when an application takes user input from an HTTP request and uses it to build a database query through unsafe string concatenation instead of safe parameter separation.
The flaw breaks the fundamental boundary between Code, the SQL instructions written by the developer, and Data, the input provided by the user.
The Classic Authentication Bypass
Imagine a standard login query where the application checks both the username and password. If the developer concatenates user input directly, an attacker can close the username string early and inject logic that always evaluates true.
Closes the literal string boundary for the username filter early.
Adds a second logic path that can make the whole condition true.
The condition '1'='1' is always true, so the database can return a matching admin row.
UNION-Based Data Extraction
The UNION operator merges the output of a second SELECT statement with the original query. Attackers abuse this when a vulnerable page prints search results back to the browser.
Step 1: Determine Column Count
Step 2: Test Data Types
Step 3: Extract Secrets
The -- marker tells the SQL parser to ignore the rest of the developer's original query, removing trailing syntax that could break the payload.
Advanced SQLi: Error-Based & Blind
What happens if the page does not print database records on screen? You pivot to side channels: error messages, true or false behavior, or time delays.
Deliberately causes a database exception that may leak sensitive data inside the error output.
Asks the database yes/no questions and watches whether the page behavior changes.
Forces a delay when a guessed condition is true, turning response time into a signal.
Secure Coding & Prevention
Filtering individual characters is a losing battle. Attackers can encode, obfuscate, or restructure payloads. The reliable fix is to separate SQL instructions from input values using parameterized queries, also called prepared statements.
The Dynamic SQLi Playground
Attack and defend the portal below. Try a normal username, then try an authentication bypass payload. Toggle the parameterized defense and watch how the compiled query changes.
Cyber Defender: Injection Shield
An automated vulnerability scanner has alerted your SOC to a SQL injection hazard inside the main corporate billing search bar. Choose the correct engineering patch immediately.
Choose your defense deployment:
Section 10 Assessment
Passing Requirement: Achieve 100% to clear the core injection track. The explanatory answer key unlocks only after every answer is correct.
-- or # in a SQLi payload?🔑 Explanatory Answer Key
1. C: Prepared statements compile the SQL structure first, then bind user input as data only. The database never treats the input as executable SQL instructions.
2. B: Comment characters cut off the remaining original query, which prevents trailing developer syntax from breaking the injection payload.
3. B: A forced delay is Time-Based Blind SQLi because the attacker reads the database answer through response timing instead of visible output.