SQL injection (SQLi) is what happens when untrusted input is mixed into a database query so the database interprets part of that input as SQL code rather than mere data. If that sounds familiar from the XSS course, it should: it's the same root cause — data treated as code — aimed at a different target. XSS subverts the browser; SQLi subverts the database, where your most sensitive data lives. It has sat near the top of the OWASP risk list for over two decades.

The Core Idea: A Query Built by String Concatenation

A web app builds SQL queries to talk to its database. The fatal pattern is constructing that query by gluing user input directly into the query string:

The developer intended the input to be a value slotted between the quotes — pure data. But the input and the query are the same string, so if the input contains SQL syntax (like a quote), it can escape the data slot and become part of the command. The database has no way to know which characters the developer wrote and which the attacker supplied — it just parses the final string as SQL.

The Canonical Example

Supply ' OR '1'='1 as the username, and watch the query's meaning change:

The injected OR '1'='1' is always true, so the WHERE clause matches every row — the query returns all users (often logging the attacker in as the first one, typically an admin). The single quote in the input closed the string the developer opened, and everything after it was read as code. That one-character breakout is the entire essence of SQLi.

Same Root Cause as XSS — Different Target

Why It's So Damaging: It Targets the Database

XSS attacks a user's session; SQLi attacks the data store itself — which makes it one of the highest-impact web vulnerabilities. Depending on the query and the database account's privileges, an attacker can:

• Read any data — dump entire tables: all users, password hashes, personal data, payment records (often via UNION, Chapter 4).
• Bypass authentication — the ' OR '1'='1 login bypass (ties to the Auth course — this is one route to account takeover with no credentials).
• Modify or destroy data — UPDATE/DELETE/DROP if the injection reaches a write or stacked query (Chapter 6).
• Escalate further — read files, run OS commands, or pivot into the network on misconfigured/over-privileged databases.

Where Injectable Input Comes From

Any data that originates outside your code and reaches a query is a candidate — not just the obvious login form. URL parameters, form fields, HTTP headers (User-Agent, cookies), JSON API bodies, and even data already stored in your database (second-order SQLi, Chapter 6) can all carry a payload. The discipline isn't "sanitize the login box" — it's treating every value that flows into a query as untrusted until it's safely parameterized.

Hands-On Exercises

Every injection has the same three moves: break out of the data context, inject your SQL, and fix up the rest of the query so it still parses. This chapter looks at how each move works — and the first question an attacker (or tester) asks is: what context is my input in?

The First Question: String or Numeric Context?

Where the input lands in the query determines how you break out of it — exactly like the injection contexts from the XSS course, but for SQL. The two main cases:

Probing: Does It Even Inject?

Before crafting an attack, a tester confirms a parameter is injectable. The classic probes:

• A lone quote ' — if it causes a database error or changed behaviour, the input is reaching the query unescaped (string context).
• Always-true vs always-false — ' OR '1'='1 (more results) vs ' AND '1'='2 (no results). A difference proves your input is altering the query's logic.
• Arithmetic — in numeric context, id=5 vs id=4+1: if both return the same record, the database evaluated 4+1 — it's numeric and injectable.

Comments: Cutting Off the Rest of the Query

After injecting, the developer's original query continues — often with a trailing quote or an AND password='...' that would break your syntax. The fix-up move is a SQL comment, which tells the database to ignore everything after it:

Putting It Together: Subverting a Login

Now the classic auth-bypass in full. The login query:

An attacker who wants to log in as a specific known user (admin) without the password supplies the username:

The Three Moves, Generalized

Every injection payload, however complex, is these three moves:

1. Break out — a ' (string context) or nothing (numeric) to escape the data slot into code position.
2. Inject — your SQL: boolean logic (OR 1=1), a UNION (Chapter 4), a stacked statement (Chapter 6), etc.
3. Fix up — a comment (-- ) to discard the trailing query, or carefully balanced quotes so the whole thing still parses.

Recognizing these three moves lets you read any payload — and the next chapters expand the middle move (what you inject) for data extraction, blind inference, and beyond.

Hands-On Exercises

All SQLi shares the root cause (Chapter 1) and the three moves (Chapter 2), but injections are classified by how the attacker gets the answer back. That channel depends on what the app shows you: query results? errors? nothing at all? The type dictates the technique — so the first thing a tester establishes is which type they're dealing with.

The Three Families

In-Band SQLi (the easy case)

The data comes back through the same channel you injected — the app's normal response. Two sub-types:

Error-Based

The app displays database error messages, and the attacker crafts input that makes the DB leak data inside an error (e.g. forcing a type-conversion error that includes a queried value). Verbose errors can reveal table names, column types, query structure, and even extracted values:

Union-Based

The most powerful in-band technique: UNION SELECT appends the results of a second query onto the original, so data from other tables appears right in the app's normal output (a product listing, search results). This is the workhorse of data extraction and gets its own chapter (Chapter 4).

Blind SQLi (no visible output)

When the app shows no query results and no errors, you're flying blind — but the injection still works; you just can't see the answer directly. Instead you ask the database true/false questions and read the answer from the app's behaviour. Two sub-types:

• Boolean-based — inject a condition and watch whether the page changes. ' AND 1=1-- (page loads normally) vs ' AND 1=2-- (page differs / no results). By substituting real conditions (' AND SUBSTRING(password,1,1)='a'-- ), you extract data one character at a time from the true/false signal.
• Time-based — when even the page response is identical for true and false, you make the database pause on "true": ' AND IF(condition, SLEEP(5), 0)-- . A 5-second delay means the condition was true. You read data through the response time.

Blind extraction is slow (one bit/character per request) but completely effective — and trivially automated (Chapter 5 + sqlmap in Chapter 10). It's covered in depth next chapter-but-one.

Out-of-Band SQLi (a separate channel)

Sometimes there's no usable in-band output and no reliable behavioural/timing difference. If the database can make outbound network requests, the attacker exfiltrates data through a different channel — typically by making the DB perform a DNS or HTTP lookup to a domain they control, with the stolen data encoded in the request:

OOB is the fallback when in-band and blind are impractical (or to speed up exfiltration), and it depends on database features and network egress being available. It's less common but worth knowing exists.

Why the Type Doesn't Change the Fix

Note the through-line: error-based, union-based, boolean-blind, time-blind, and out-of-band are all the same vulnerability — an injectable query — read through different channels. Defenders sometimes try to close the channel (hide errors, normalize responses), which only forces the attacker to a different type. The fix targets the cause, not the readout: parameterized queries (Chapter 7) prevent the injection from happening at all, so there's nothing to read back through any channel.

Hands-On Exercises

Chapter 3 introduced UNION-based SQLi as the most powerful in-band technique. This chapter works it in full, because it's the canonical way an attacker turns "I can inject" into "I have your entire users table." The idea: UNION lets you bolt a second query onto the first, so data from any table the DB account can read appears in the app's normal output. (Defensive framing as always — practise only on targets you own / training labs.)

What UNION Does

UNION SELECT combines the rows of two SELECT statements into one result set. If the app displays the results of its query, an injected UNION SELECT makes your chosen data show up alongside (or instead of) the legitimate rows:

But UNION has two strict requirements that the attacker must satisfy first, and the early steps of every union attack are about discovering them.

Requirement 1: Matching Column Count

A UNION requires both queries to return the same number of columns, or the database errors. So step one is finding how many columns the original query has. Two standard methods:

ORDER BY probing

Increase the ORDER BY column index until it errors — the last value that works is the column count:

UNION SELECT NULL probing

Or increase the number of NULLs until the union succeeds (NULL is type-compatible with anything, so it isolates the count question from the type question):

Requirement 2: Compatible Column Types

The columns you inject must be type-compatible with the original's columns in the positions you want to display — specifically, the data you want to read (usually text) must go in a column the app renders as a string. Find a string-friendly column by placing a test marker:

Whichever marker shows up in the page is a column you can exfiltrate string data through. Now you know the count and a usable column position — you can extract.

Reading the Schema: information_schema

To steal data you need to know what tables and columns exist. SQL databases expose their own structure through a metadata catalogue — most commonly information_schema — which you can query through the union:

The Full Attack, Start to Finish

1. Confirm injectable — a lone ' or ' OR '1'='1 changes behaviour (Chapter 2).
2. Find the column count — ORDER BY n until it errors, or UNION SELECT NULL,... until it works.
3. Find a displayable text column — place a string marker in each position.
4. Map the schema — query information_schema for tables and columns.
5. Extract — UNION SELECT the target columns (concatenated if needed) and read them from the output.

Hands-On Exercises

Union extraction (Chapter 4) needs the app to show query results. Often it doesn't — a login that just says "success" or "failure," a search that returns a generic page. The query is still injectable, but you can't see the answer. Blind SQLi recovers the data anyway, by turning the application into a yes/no oracle and reading one bit at a time. It's slower than union-based, but no less complete — and fully automatable. (Defensive framing: own systems / training labs only.)

The Core Idea: The App as a Boolean Oracle

You can't see data, but you can ask the database a true/false question and observe whether the app behaves differently. If you can reliably distinguish "the condition was true" from "the condition was false," you can ask questions about the data and reconstruct it bit by bit. The two ways to get that true/false signal define the two sub-types.

Boolean-Based Blind

Here the page content differs (even subtly) between a true and a false condition — different text, different length, present-or-absent results, a 200 vs a 500. First establish the tell:

Now swap the constant for a question about the actual data, and read the answer from which page you get back:

Binary Search: ~7 Requests per Character

Testing every possible character one by one is wasteful. Instead use a binary search on each character's ASCII value — each request halves the remaining range, so a full byte (0–127 printable, really ~95 candidates) is pinned in about 7 requests:

Then advance to position 2 (SUBSTRING(...,2,1)), repeat, and you've reconstructed the whole password. You typically first extract the length (' AND LENGTH(password)=N) so you know when to stop.

Time-Based Blind

Sometimes the page is identical for true and false — no content difference at all. Then you manufacture your own signal: make the database pause when the condition is true, and read the answer from the response time:

Why Blind Is Slow but Not Safe

The contrast with union-based is stark and worth internalizing:

Hands-On Exercises

So far the injections have read data through SELECT queries. But SQLi isn't limited to reads — it can modify data, chain whole new statements, and even lie dormant until triggered later. This chapter covers the write-side and the trickier delivery patterns, including the one that defeats input-time validation entirely. (Defensive framing — own systems / labs only.)

Injection Into Write Statements

Any statement built with user input is injectable, not just SELECT. An UPDATE or INSERT that concatenates input can be subverted to change other columns or rows:

The same applies to WHERE clauses on writes: an injectable UPDATE … WHERE id=$id with id = 5 OR 1=1 updates every row. A DELETE with the same flaw deletes the whole table. So injection into a write is an integrity and availability attack, not just confidentiality.

Stacked Queries: Running Entirely New Statements

Some database drivers allow multiple statements separated by a semicolon in one call. Where that's enabled, an attacker can append a completely separate command after the original — turning a read into a write, a drop, or anything else:

Authentication Bypass — the Write/Logic Variant

Chapter 2 showed login bypass via SELECT. Note it ties to the whole Auth course: injection can also create or elevate accounts (the role='admin' trick above), reset another user's password through an injectable update, or satisfy a privilege check — turning a query-construction bug into full account compromise with no credential. SQLi is frequently the first step in a breach, then pivots through these write capabilities.

Second-Order SQLi: The Payload That Waits

The subtlest and most important pattern in this chapter. Second-order (stored) SQLi splits the attack across two requests: the payload is safely stored first, then triggers later when some other code reads it back into a query unsafely.

The Unifying Point

Reads, writes, stacked statements, and second-order delivery look different, but they're all the same root cause from Chapter 1 — untrusted input parsed as SQL — at different statement types and via different timing. And they all collapse under the same fix: a parameterized query binds input as data regardless of whether the statement is a SELECT or an UPDATE, whether stacking is on or off, and whether the value arrived just now or was read from a table. One discipline, applied to every query, closes all of it (Chapter 7).

Hands-On Exercises

Six chapters of attacks, all the same root cause and all ending with the same sentence: "...impossible under parameterized queries." This is that chapter. Parameterized queries (a.k.a. prepared statements with bound parameters) are the defence against SQL injection — not one option among several, but the actual fix that removes the vulnerability rather than papering over it. Everything else (Chapter 8) is defence in depth on top.

The Core Idea: Separate the Query From the Data

Recall the root cause (Chapter 1): SQLi happens because the query and the data are the same string, so the database can't tell which characters are code and which are input. Parameterization fixes this at the source by sending them on two separate channels:

1. You send the query text with placeholders (? or :name) where values go — and only the placeholders, no values.
2. You send the values separately, bound to those placeholders.
3. The database parses and plans the query first (with placeholders), then slots the values in as pure data — after parsing is already done.

Before & After

The Same Fix Across Languages

What Parameters Can — and Can't — Bind

Placeholders bind values (the things in WHERE x = ?, VALUES (?), SET col = ?). They cannot bind identifiers — table names, column names, ORDER BY directions, LIMIT in some drivers — because those are part of the query structure, decided at parse time. This matters for dynamic queries:

Why This Beats Escaping

Escaping (manually backslashing or doubling quotes in input) tries to make input safe to concatenate. It's strictly worse than parameterization and only a last resort (Chapter 8), because: it's easy to forget on one query out of hundreds; it's database- and charset-specific (multi-byte encoding tricks have bypassed escaping); it does nothing for numeric context (no quotes to escape, Chapter 2); and it corrupts legitimate data. Parameterization sidesteps all of it — there's nothing to escape because the data never enters the SQL text. Prefer parameterized queries; treat escaping as a fallback for the rare case you truly can't parameterize.

A Bonus: Performance and Clarity

Parameterized queries aren't only safer — they're often faster and cleaner. The database can parse and cache the query plan once and reuse it for many different parameter values (no re-parsing per request), and the code is more readable (no quote-juggling). Security, performance, and clarity all point the same way: there is essentially no reason to build queries by concatenation. The rule is simply: parameterize every query, every time.

Hands-On Exercises

Parameterized queries (Chapter 7) are the fix. This chapter is everything you add around them so that a single mistake isn't catastrophic — and, just as importantly, a clear-eyed account of what each extra layer does and does not achieve. The recurring caution: none of these replaces parameterization; they reduce likelihood and limit blast radius.

Layer 1: Input Validation (allowlist)

Validate that input matches its expected shape — an ID is a positive integer, an email looks like an email, a status is one of a fixed set. Reject anything off-format (an allowlist, not a blocklist of "bad characters"):

Layer 2: Least-Privilege Database Accounts

The app should connect to the database as an account with the minimum permissions it actually needs — not as root/sa/a DB owner. This doesn't prevent injection, but it dramatically limits the damage if one occurs:

• Read-only where possible — a reporting endpoint's account with only SELECT can't be used to UPDATE/DROP via a stacked query.
• Scope to needed tables — no access to tables the feature doesn't use.
• No dangerous privileges — no FILE, no ability to create users, no xp_cmdshell; these are the rungs from SQLi to OS compromise (Chapter 1).
• Separate accounts per service — a breach of one is contained.

Least privilege is the difference between "an attacker read one table" and "an attacker dropped the database and ran commands on the server."

Layer 3: Stored Procedures (only if parameterized inside)

Stored procedures are often cited as a SQLi defence — but the protection comes from how they use parameters, not from being a stored procedure:

Layer 4: ORMs & Query Builders

ORMs (Sequelize, Hibernate, Django ORM, ActiveRecord, etc.) parameterize by default — calling User.find({ where: { id } }) generates a bound query, which is why ORM-heavy code has far less SQLi. But they're not a force field: raw query escape hatches reintroduce it (covered fully next chapter). For now: ORMs are a strong layer because they make the safe path the default, but their raw-SQL methods are where injection creeps back.

Layer 5: Escaping — Last Resort Only

Manually escaping input (via a vetted, charset-correct library function) to make it safe to concatenate is the weakest option and should be reserved for the rare case you genuinely can't parameterize. Recap from Chapter 7: it's fragile (charset/multi-byte bypasses), useless for numeric context, easy to forget, and corrupts data. If you find yourself escaping, ask first whether you can parameterize or use an allowlist instead.

Layer 6: WAFs — A Backstop, Not a Fix

A Web Application Firewall inspects requests and blocks ones matching known SQLi patterns. It can stop opportunistic/automated attacks and buy time to patch — useful as an outer layer. But it's pattern-matching, so it's bypassable (encoding, comments, case tricks, novel payloads — the same blocklist-loses problem from the XSS course), and it does nothing about second-order injection or the underlying bug.

The Layered Picture

Stack them — but the load-bearing wall is parameterization; everything else assumes it's there and exists to catch what slips through (a forgotten query, a new bug) and to contain the damage.

Hands-On Exercises

ORMs and NoSQL databases made classic string-concatenated SQLi rarer — but, exactly like framework auto-escaping did for XSS (the "less, not gone" story), they didn't eliminate injection. They moved it. This chapter covers where injection hides in ORM-heavy code and the NoSQL cousin that catches teams who think "we don't use SQL, so we're safe."

ORMs: Safe by Default, Until the Escape Hatch

ORMs (Sequelize, Prisma, Hibernate/JPA, Django ORM, ActiveRecord, Eloquent) generate parameterized queries automatically for normal operations — which is why ORM code has far less SQLi. The danger is the raw-SQL escape hatches every ORM provides, where you drop to hand-written SQL and the auto-parameterization stops:

ORM Pitfalls Beyond Raw Queries

Even without dropping to raw SQL, ORMs have sharper edges than "always safe":

• Concatenating into a raw fragment — whereRaw("age > " + input) is injectable even though it's "using the ORM."
• Dynamic column/table/order names — ORMs can't parameterize identifiers either (Chapter 7); passing a user-chosen column/sort needs an allowlist, or it's injectable.
• Operator/structure injection — some ORMs build queries from objects; if you spread untrusted JSON straight into a where clause, an attacker may inject operators (this overlaps with NoSQL injection below).
• "LIKE" and wildcard handling — user input in a LIKE needs its wildcards (%, _) handled, separate from SQLi but a related correctness/abuse issue.

NoSQL Injection: The Cousin That Surprises People

"We use MongoDB, so SQL injection doesn't apply." True for SQL injection — but NoSQL databases have their own injection class, the same root cause (untrusted input changing query structure) in a different query language. The classic is operator injection in MongoDB:

Defending NoSQL

• Validate types & structure — ensure password is a string, not an object; reject request fields that are objects/arrays where a scalar is expected. This kills operator injection at the source.
• Cast/coerce inputs — explicitly treat values as the type you expect (String(req.body.password)) before they reach the query.
• Avoid dangerous operators — disable/forbid $where and JavaScript execution; don't pass user input into $regex unescaped.
• Use the driver/ODM safely — Mongoose schemas enforce types (a String field rejects an object); don't bypass them with loose queries built from raw request bodies.

The Persistent Lesson

Across ORMs and NoSQL, the same pattern from the XSS course recurs: modern tools make the safe path the default, which slashes injection rates, but every escape hatch and every "spread untrusted input into the query" is where it returns. The defences also rhyme — keep untrusted input as data, never let it become query structure: parameterize raw SQL, allowlist identifiers, and validate types so a JSON object can't sneak in where a string belongs. The framework helps; it doesn't absolve you of the data-vs-code discipline.

Hands-On Exercises

The finale turns the course into practice: how to test for SQLi, how the standard tooling works, the broken-defence patterns to recognize, and a single deployable checklist that pulls all ten chapters together. (Test only systems you own or are authorized to assess.)

How to Test for SQLi

1. Map every input that reaches a query — URL params, form fields, JSON bodies, headers, cookies — and remember stored values too (second-order, Chapter 6).
2. Probe injectability — a lone ' (error/changed behaviour), ' OR '1'='1 vs ' AND '1'='2 (logic change), arithmetic like 4+1 in numeric params (Chapter 2).
3. Identify the context & type — string vs numeric (Ch. 2); in-band, blind, or out-of-band (Ch. 3) — this dictates the technique.
4. Confirm impact safely — extract something harmless and unique (e.g. @@version / version()), not destructive payloads, to prove the finding.
5. Check for blind — if no output/errors, test boolean (page difference) and time-based (SLEEP) inference (Chapter 5).

The Broken-Defence Catalogue

The Hardening Checklist

How the Course Fits Together

The arc: understand the bug (Ch. 1 data-vs-code, Ch. 2 anatomy), the channels & techniques (Ch. 3 types, Ch. 4 union, Ch. 5 blind, Ch. 6 writes/stacked/second-order), then the defences — parameterized queries as the foundation (Ch. 7), defence in depth around it (Ch. 8), the realities of modern ORMs/NoSQL (Ch. 9), and operational testing/hardening (Ch. 10). It also pairs with the wider security set: SQLi and XSS are the two great injection bugs (database vs browser); Auth is what SQLi login-bypass attacks; and like all of them, the defence is a discipline applied everywhere, because the weakest query sets your exposure.

Hands-On Exercises