How to Fix SQL Injection With Parameterized Queries

What makes f-string SQL dangerous

A search endpoint that builds queries with string formatting is trivially exploitable:

# Vulnerable - never do this
@app.get("/search")
def search():
    q = request.args.get("q", "")
    query = f"SELECT id, username, email FROM users WHERE username LIKE '%{q}%'"
    cur.execute(query)
    return jsonify(cur.fetchall())

An attacker sends q=' OR 1=1-- and the query becomes:

SELECT id, username, email FROM users WHERE username LIKE '%' OR 1=1--%'

OR 1=1 is always true, so every row in the table comes back. More advanced payloads can use UNION SELECT to read from other tables, or call database functions that exfiltrate data out-of-band.

Fix: use parameterized queries

Pass the value as a separate argument - never interpolate it into the SQL string:

# Safe - parameterized with psycopg2
@app.get("/search")
def search():
    q = request.args.get("q", "").strip()
    cur.execute(
        "SELECT id, username, email FROM users WHERE username LIKE %s",
        (f"%{q}%",)   # the LIKE wildcards wrap the value, not the query
    )
    return jsonify(cur.fetchall())

The driver sends the SQL template and the value to the database as two separate messages. The database engine never parses the value as SQL - ' OR 1=1 -- becomes the literal search string %' OR 1=1 --%, which matches zero rows.

Why %s instead of format strings

%s is psycopg2's placeholder syntax (not Python's % string operator). When you call cur.execute(sql, params), psycopg2 handles quoting and escaping according to the PostgreSQL wire protocol, which is always correct regardless of what characters the value contains. The same pattern applies in other drivers:

Verify the fix

# Normal search - still works
curl "http://localhost:8000/search?q=alice"

# Injection payload - returns empty list, not all users
curl "http://localhost:8000/search?q=' OR 1=1--"

After switching to parameterized queries, static analysis tools like Bandit and semgrep stop flagging the endpoint, and a SQL injection scanner returns zero findings.