What Is SQLi?

Chapter 1

What SQLi Is & Why It Works

Untrusted input becomes query code — the data-vs-code trust boundary, again

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:

// a login lookup built by concatenation — the classic vulnerability
const query = "SELECT * FROM users WHERE username = '" + username + "' AND password = '" + password + "'";

// intended, with username = "philip":
// SELECT * FROM users WHERE username = 'philip' AND password = '...'

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:

// attacker enters username:  ' OR '1'='1
SELECT * FROM users WHERE username = '' OR '1'='1' AND password = '...'
                                     └── the attacker's input is now SQL logic ──┘

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

	XSS	SQL Injection
Untrusted input becomes…	HTML/JavaScript	SQL
Interpreted by	the browser	the database
Runs where	client-side (victim's browser)	server-side (your database)
Breakout character	`<` (opens a tag)	`'` (closes a string)
Primary fix	context-aware output encoding	parameterized queries

One mental model spans both courses

Every injection bug — SQLi, XSS, command injection, LDAP injection — is the same mistake: untrusted data crosses a boundary where it gets parsed as code instead of staying data. The defences rhyme too: keep data separate from the code channel. For XSS that's encoding on output; for SQLi it's sending the query and the data on separate channels so the data is never parsed as SQL (parameterized queries, Chapter 7). If you understood "data vs code" from XSS, you already understand the heart of SQLi — only the syntax and the target differ.

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.

A single SQLi can mean a total database breach — and they happen at scale

Because the vulnerability sits between the app and where all the data lives, one injectable parameter can expose the whole database. Real-world SQLi breaches have leaked hundreds of millions of records (it was the vector behind a long list of major incidents). It's also frequently automatable end to end — tools like sqlmap (Chapter 10) can find and exploit it with little manual effort, which means even low-skill attackers can weaponize a single mistake. This is why SQLi, despite being old and well-understood, remains both common and catastrophic — and why the one real fix (Chapter 7) must be applied everywhere, not just on the obvious inputs.

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

Exercise 1

In your own words, explain the root cause of SQLi in "data vs code" terms. Take the concatenated login query and show exactly how the input ' OR '1'='1 changes its meaning, identifying which character causes the breakout and why the database can't tell code from data.

📄 View solution

Exercise 2

Draw the parallel between SQLi and XSS: for each, name what the input becomes, who interprets it, where it runs, the breakout character, and the primary fix. Then state the single root cause both share and why understanding one helps you understand the other.

📄 View solution

Exercise 3

List five distinct things an attacker could achieve through a single SQLi, and for each note what it depends on (query type, DB privileges). Then explain why "we sanitize the login form" is an inadequate framing of the defence, given where injectable input can originate.

📄 View solution

Chapter 1 Quick Reference

SQLi = untrusted input mixed into a query so the database parses it as SQL code, not data
Root cause = data treated as code — the same bug as XSS, aimed at the database instead of the browser
The fatal pattern: building queries by string concatenation of user input
Canonical breakout: ' OR '1'='1 — the ' closes the string, the rest becomes always-true logic → returns all rows / login bypass
The database can't distinguish developer SQL from injected input — it parses the final string
Impact: read any data, bypass auth, modify/destroy data, sometimes run OS commands — a single param can breach the whole DB
Injectable input is everywhere: URLs, forms, headers, cookies, JSON, even stored data — not just the login box
One model spans injection bugs: keep data separate from the code channel (parameterized queries, Chapter 7)
Next chapter: anatomy of an injection — string/numeric contexts, comments, and subverting a login