SQL Injection Cheat Sheet for Data Engineers (2026)

# ALWAYS this (parameterized)
cursor.execute("SELECT * FROM users WHERE id = %s", (user_id,))

# NEVER this (string concatenation)
cursor.execute(f"SELECT * FROM users WHERE id = {user_id}")

If you remember nothing else from this page, remember this contrast. The top form is safe in every database driver and every framework. The bottom form is exploitable in all of them.

# Vulnerable query (string concatenation)
query = "SELECT * FROM users WHERE name = '" + user_input + "'"

# If user_input = "' OR 1=1 --"
# Resulting query:
SELECT * FROM users WHERE name = '' OR 1=1 --'
# Returns ALL rows. Authentication bypassed.

# ────────────────────────

# Safe: parameterized query
cursor.execute(
    "SELECT * FROM users WHERE name = %s",
    (user_input,)
)

String concatenation lets the attacker close the string and inject arbitrary SQL. Parameterized queries keep the user input as data — the database never parses it as SQL.

-- Boolean-based: does the page load differently?
' AND (SELECT COUNT(*) FROM users) > 100 --

-- Time-based: does the response take 5 seconds?
' AND pg_sleep(5) --

-- If the response is delayed, the attacker knows
-- the injected SQL executed successfully.

# ────────────────────────

# Also safe: using an ORM
User.objects.filter(name=user_input)
# Django ORM parameterizes automatically

Blind injection works without visible output. The attacker probes by timing or by checking how the page renders. ORM query builders parameterize automatically and shut the door.

-- Original query returns 3 columns
SELECT id, name, email FROM products WHERE id = 1

-- Attacker input: 1 UNION SELECT username, password, null FROM admin_users
-- Resulting query:
SELECT id, name, email FROM products WHERE id = 1
UNION SELECT username, password, null FROM admin_users
-- Now the admin credentials appear in the product listing.

-- ────────────────────────

-- Defense in depth: restrict DB user permissions
GRANT SELECT ON products TO app_readonly;
-- app_readonly cannot access admin_users table
-- Even if injection worked, the query would fail

UNION-based attacks let the attacker pull data from tables your application never queries. Parameterized queries block the injection. Least-privilege database users limit blast radius if anything slips through.

# Step 1: Safe insertion (parameterized)
INSERT INTO users (name) VALUES (%s)  # stores: Robert'; DROP TABLE users;--

# Step 2: Unsafe downstream query (string concat)
query = f"SELECT * FROM logs WHERE user_name = '{row['name']}'"
# The stored value is now injected into a new query.

# ────────────────────────

# Safe downstream query
cursor.execute(
    "SELECT * FROM logs WHERE user_name = %s",
    (row['name'],)
)
# Parameterized even though the input came from our DB

The original INSERT was safe, but the downstream SELECT trusted the stored value. Parameterize every query — even ones reading 'your own' data. The DB doesn't remember which strings were once user input.

# BAD: dynamic table name from config
table = config['source_table']
query = f"SELECT * FROM {table}"

# GOOD: validate against allowlist
ALLOWED_TABLES = {'users', 'orders', 'products'}
if table not in ALLOWED_TABLES:
    raise ValueError(f"Unknown table: {table}")
query = f"SELECT * FROM {table}"  # safe after validation

You cannot parameterize identifiers in most drivers. Validate them against an allowlist before interpolating.

# BAD: API parameter directly in ORDER BY
sort_col = request.args.get('sort_by', 'id')
query = f"SELECT * FROM users ORDER BY {sort_col}"

# GOOD: allowlist the column
SORTABLE = {'id', 'name', 'created_at'}
if sort_col not in SORTABLE:
    sort_col = 'id'
query = f"SELECT * FROM users ORDER BY {sort_col}"

Allowlist ORDER BY columns. A caller who controls the sort column controls the query plan and can probe for additional vulnerabilities.

# BAD: Jinja template (string substitution)
sql = "SELECT * FROM events WHERE dt = '{{ params.date }}'"

# GOOD: use parameters argument
PostgresOperator(
    task_id='query_events',
    sql="SELECT * FROM events WHERE dt = %(date)s",
    parameters={'date': '2026-01-15'},
)

Jinja is string substitution, not parameterization. Operators expose a parameters argument for a reason — use it for values, and validate any dynamic identifiers in a Python task upstream.

# COPY itself is safe (treats all data as literal values)
COPY staging_table FROM '/data/upload.csv' WITH (FORMAT csv);

# But downstream processing MUST be parameterized
cursor.execute(
    "INSERT INTO clean_table SELECT * FROM staging_table WHERE status = %s",
    ('active',)
)

COPY treats every byte as literal data. The risk is the next query that reads the staging table. Parameterize it the same as any other query.

# Safe: ORM query
session.query(User).filter(User.name == user_input).all()

# Safe: text() with bind parameters
from sqlalchemy import text
session.execute(text("SELECT * FROM users WHERE name = :name"), {"name": user_input})

# UNSAFE: raw string formatting
session.execute(f"SELECT * FROM users WHERE name = '{user_input}'")

session.query and text() with bind parameters are both safe. f-strings against execute() are not.

# Safe: ORM query
User.objects.filter(name=user_input)

# Safe: raw query with parameters
User.objects.raw("SELECT * FROM users WHERE name = %s", [user_input])

# UNSAFE: string formatting in raw query
User.objects.raw(f"SELECT * FROM users WHERE name = '{user_input}'")

ORM filter() is always safe. raw() is safe only if you pass parameters as the second argument — never with f-strings.

# Safe: psycopg2 parameterized
cursor.execute("SELECT * FROM users WHERE name = %s", (user_input,))

# Safe: asyncpg parameterized
await conn.fetch("SELECT * FROM users WHERE name = $1", user_input)

# UNSAFE: string concatenation
cursor.execute("SELECT * FROM users WHERE name = '" + user_input + "'")

# UNSAFE: f-string
cursor.execute(f"SELECT * FROM users WHERE name = '{user_input}'")

Both drivers parameterize natively. psycopg2 uses %s placeholders, asyncpg uses $1, $2, etc. Never close them with string concatenation.