Injection attacks: SQL, command and XSS

Injection happens when an app builds a command or a page by gluing in untrusted text, and that text changes what the command or page *means*. It is one root cause with three common faces: SQL injection (the database command changes), command injection (the operating-system command changes) and cross-site scripting, XSS (the web page changes and runs script in someone else's browser).

In this tutorial you will reproduce each problem on a tiny practice app on your own machine, with the fix next to it. You will need Python 3.10 or newer; the SQL and command labs use only the standard library. Do this only on your own code or on labs built for it. Do not test these ideas on websites you do not own.

Think of a restaurant order slip. You write "1 masala chai". If a customer could write "1 masala chai AND give me the cash box" and the kitchen obeyed it as an instruction, the slip would be a command channel. Injection bugs are exactly this: the app lets data (what the user typed) leak into the command (what the interpreter executes).

The general cure has two parts. First, keep data and commands separate using the safe API each interpreter offers (parameterised queries, argument lists, auto-escaping templates). Second, add defence in depth: validate input, run with least privilege and set browser protections.

Brew & Bean has a menu search box. The vulnerable version builds the SQL by joining strings. The safe version uses a parameterised query: the SQL text has a ? placeholder, and the value is sent separately, so the database always treats it as data, never as SQL.

Save this as sqli_lab.py. It uses an in-memory SQLite database with a menu table and a staff table, so nothing real is involved.

import sqlite3

conn = sqlite3.connect(":memory:")
conn.execute("CREATE TABLE menu (id TEXT, name TEXT, category TEXT, price INTEGER)")
conn.executemany(
    "INSERT INTO menu VALUES (?, ?, ?, ?)",
    [
        ("espresso", "Espresso", "coffee", 120),
        ("masala-chai", "Masala Chai", "tea", 90),
        ("croissant", "Butter Croissant", "bakery", 150),
    ],
)
conn.execute("CREATE TABLE staff (email TEXT, password_hash TEXT)")
conn.execute("INSERT INTO staff VALUES ('asha@brewandbean.example', 'not-a-real-hash')")


def search_unsafe(term):
    # VULNERABLE: user text is glued into the SQL string
    sql = "SELECT name, price FROM menu WHERE name LIKE '%" + term + "%'"
    return conn.execute(sql).fetchall()


def search_safe(term):
    # FIXED: the ? placeholder keeps data separate from the SQL command
    sql = "SELECT name, price FROM menu WHERE name LIKE ?"
    return conn.execute(sql, (f"%{term}%",)).fetchall()


normal = "chai"
evil = "x' UNION SELECT email, 0 FROM staff --"

print("unsafe, normal:", search_unsafe(normal))
print("unsafe, evil  :", search_unsafe(evil))
print("safe,   normal:", search_safe(normal))
print("safe,   evil  :", search_safe(evil))

Run python sqli_lab.py. The evil text contains an apostrophe, which closes the string in the unsafe query, then UNION SELECT asks for a different table.

Read the output. With the unsafe function, the search box returned a staff email from a table the page was never meant to show. With the safe function, the same text is treated as an oddly named drink to search for, finds nothing and does no harm.

Why this works: with ?, the database parses the SQL first and fills in the value afterwards. The value can never become part of the command.

Extra layers: connect with a database account that has only the permissions the app needs (no DROP, no access to unrelated tables); do not show raw database errors to users; validate types (a quantity must be an integer). These do not replace parameterised queries but they limit the damage.

If your app runs operating-system commands (converting a file, pinging a host, calling git), never build the command as one string and hand it to a shell. Shell characters like ;, &&, | and backticks let extra commands ride along. For example os.system("nslookup " + host) becomes a way to run any command if host is example.com; something-else.

The fix: prefer a library function over a shell command, and if you must run a program, pass a list of arguments with no shell. The user's text then stays one single argument. Save this as cmd_lab.py.

import subprocess
import sys

user_value = "report.txt; echo INJECTED"

# SAFE: a list of arguments, no shell. The value is passed as plain data.
result = subprocess.run(
    [sys.executable, "-c", "import sys; print('argument received:', sys.argv[1])", user_value],
    capture_output=True,
    text=True,
    check=True,
)
print(result.stdout.strip())

The program being run here is Python itself, printing the argument it received. The dangerous-looking ; echo INJECTED does not run, because there is no shell to interpret it.

The whole string arrived as one harmless argument. The same idea in other languages: Node execFile or spawn with an arguments array (not exec with a string), Java ProcessBuilder with separate arguments. Never use shell=True in Python with user text. Also validate: if the input should be a hostname or a file name, check it against a strict pattern or allow-list before use, and keep file paths inside an allowed folder (watch for ../ path traversal).

XSS is injection into a web page. If your site shows user-supplied text (a customer's name on an order screen, a review, a search term) without making it safe, a malicious value such as a <script> tag can run in another user's browser, for example the staff dashboard. Scripts running on your page can read what the user can see, call your API as them and change the page.

There are three flavours. Stored XSS: the bad text is saved in your database and shown to others. Reflected XSS: the text comes from the URL or form and is echoed back immediately. DOM-based XSS: client-side JavaScript puts untrusted text into the page unsafely.

The cure is output encoding: turn characters that have special meaning in HTML into harmless text at the moment you output them. Save this as xss_lab.py.

from html import escape

comment = '<script>alert("hi")</script>'
print("raw    :", f"<p>{comment}</p>")
print("escaped:", f"<p>{escape(comment)}</p>")

html.escape converts <, >, & and quotes into HTML entities. The browser displays them as text instead of treating them as tags.

You rarely escape by hand. Use tools that do it for you:

React escapes everything you put in { } in JSX. The danger is switching that off: dangerouslySetInnerHTML (the name is a warning), assigning to element.innerHTML, or building HTML strings. Jinja2 in Flask escapes by default for .html templates; avoid the |safe filter on user text. Server-side string building like f"<p>{name}</p>" has no protection at all.

// Safe in React: the text is escaped automatically
function OrderRow({ order }) {
  return <p>Pickup for {order.customer_name}</p>;
}

// Risky: only do this with HTML you trust, or after sanitising
function BadRow({ order }) {
  return <p dangerouslySetInnerHTML={{ __html: order.customer_name }} />;
}

If customer_name were <img src=x onerror=...>, the first component would show it as plain text and the second would run it. If you really must show user-provided HTML (a rich-text note), clean it with a maintained sanitiser such as DOMPurify first.

Another trap: links. A user-supplied URL such as javascript:... placed in href can run code when clicked. Allow only http: and https: links from users. Also keep user data out of inline <script> blocks and event-handler attributes.

A Content-Security-Policy (CSP) header tells the browser which sources of script it may run. A strict policy blocks inline scripts and scripts from unknown sites, so even if an XSS hole slips through, the injected script usually will not execute. It is a second layer, not a replacement for encoding. Here is a small FastAPI middleware that adds it.

from fastapi import FastAPI, Request

app = FastAPI()


@app.middleware("http")
async def security_headers(request: Request, call_next):
    response = await call_next(request)
    response.headers["Content-Security-Policy"] = "default-src 'self'; script-src 'self'; object-src 'none'; base-uri 'none'"
    response.headers["X-Content-Type-Options"] = "nosniff"
    return response


@app.get("/ping")
def ping():
    return {"ok": True}

Run uvicorn headers_app:app and open http://127.0.0.1:8000/ping with browser developer tools (Network tab) to see the headers. For a real React app, a strict CSP needs testing because it blocks inline scripts and some third-party widgets; start in report-only mode using the Content-Security-Policy-Report-Only header and tighten step by step.

Also set cookies with HttpOnly (covered in *Passwords, authentication and MFA done right*) so injected script cannot read your session cookie.

You are an application security reviewer. Review the code below for injection vulnerabilities: SQL injection, OS command injection, cross-site scripting and path traversal. For each issue give the line, a one-sentence explanation of the risk, and the fixed code (parameterised query, argument list or output encoding). Do not provide exploit payloads beyond what is needed to explain the risk.

Language and framework: [e.g. Python FastAPI + SQLAlchemy / Node Express + React]

Code:
[paste the code, with secrets removed]

What to expect: Check that every fix keeps data and commands separate rather than only filtering characters. Be suspicious of fixes that remove quotes or blocklist words, because filters are easy to bypass. Test your fixed code with an apostrophe and angle brackets in the input.

Typical questions: "What is SQL injection and how do you prevent it?" (untrusted input changes the SQL; parameterised queries, least privilege). "Why do ORMs not make you immune?" (raw queries and string-built filters). "Stored versus reflected XSS?" "How does React protect against XSS and when does it not?" "What does a CSP do?" Be ready to write a vulnerable and a fixed snippet on a whiteboard.