Parameterized Queries Have One Blind Spot

You parameterize every query. But dynamic ORDER BY clauses can't be bound — and attackers use that gap for blind SQL injection.

Dafallah Ibrahim

— 2 min read
Share

You parameterize every query. Your ORM escapes inputs. You sleep well. But if any query builds an ORDER BY, GROUP BY, or LIMIT clause from user input, you still have an injection vector.

The problem is structural: SQL parameterization only works for values, not identifiers. Column names, table names, sort directions — none of these can be bound as parameters in any database engine. And that gap is where experienced teams still get burned.

Why this matters

Most injection vulnerabilities reported today aren't the naive WHERE id = + userInput pattern. They live in pagination, sorting, and dynamic column selection — features that feel safe because they never touch a WHERE clause.

Consider a typical API: GET /users?sort=email&dir=desc. If your backend concatenates that into ORDER BY email DESC, an attacker controls the SQL structure. No amount of parameter binding on other parts of the query will help.

How it works

SQL engines distinguish between two input types:

  • Values — literals compared against (WHERE status = 'active'). These CAN be parameterized.
  • Identifiers — structural elements like column names and keywords (ORDER BY, GROUP BY). These CANNOT.

When you write ORDER BY ${sortColumn}, you're injecting raw user input into the query structure. A crafted payload like this turns your sorting feature into a blind injection oracle:

(CASE WHEN (SELECT SUBSTRING(password,1,1)
 FROM users WHERE username='admin')='a'
 THEN id ELSE email END)

The attacker can't see the output directly, but they can infer data character-by-character from the order of returned rows. In some databases, a semicolon in the input even enables stacked queries — appending entirely new statements.

Where this helps

  • Sortable API endpoints — any ?sort= or ?order= parameter reaching raw SQL.
  • DataTable and grid components — frontend widgets that send column names to the backend.
  • Dynamic report builders — user-configurable columns and grouping.
  • Admin dashboards — any UI letting users pick which column to sort by.

Watch out

ORMs don't automatically fix this. Many pass ORDER BY inputs as raw strings unless you explicitly validate them. Regex-based filtering is fragile — attack payloads are creative. And don't forget nested injection: even a validated column name is dangerous if paired with an unvalidated ASC/DESC direction.

Try it yourself

The only safe approach is an allowlist. Validate against known values before touching the query:

SORT_COLUMNS = {"id", "email", "created_at"}
SORT_DIRECTIONS = {"asc", "desc"}

def safe_order_by(sort: str, direction: str) -> str:
    col = sort if sort in SORT_COLUMNS else "id"
    direction = direction.lower() if direction.lower() in SORT_DIRECTIONS else "asc"
    return f"ORDER BY {col} {direction.upper()}"

No parameter binding needed — the allowlist guarantees only safe strings reach the SQL.

TL;DR

  • What changed: SQL parameterization can't protect identifiers like column names in ORDER BY clauses.
  • Why it matters: Attackers exploit dynamic sorting for blind injection — exfiltrating data row by row.
  • What to try today: Audit every ORDER BY built from user input and replace it with an allowlist.

Read more