SQL Injection Prevention

18 min read

SQL injection is the oldest trick in the web-security book, and it still tops breach reports decades later. The fix is always the same: let the database driver bind your values as data, never paste them into the SQL text yourself. This chapter shows how Rust’s SQLx makes the safe path the obvious one, and how to handle the genuinely dynamic cases (sorting, filtering) without opening a hole.

Quick Overview

SQL injection happens when user input is concatenated into a SQL string, so an attacker can break out of the value and inject their own SQL. The defense is parameterized queries (also called prepared statements or bound parameters): you send the SQL with placeholders (? or $1) and the values separately, and the database treats every value as opaque data — never as code.

For a TypeScript developer this should feel familiar: pg’s pool.query(sql, params) and Prisma’s tagged-template $queryRaw already parameterize. Rust’s SQLx goes one step further — bound parameters are the only ergonomic way to pass a value, and the optional query! macro can verify your SQL against a real database at compile time. This file focuses narrowly on injection: bind, never format. Validating the shape of input before it reaches the database is covered in Input Validation.

Note: The examples use SQLx 0.8 with the bundled SQLite driver so they run with zero setup (sqlite::memory:). The same bind/placeholder API applies to PostgreSQL and MySQL — only the placeholder syntax differs ($1 for Postgres, ? for SQLite/MySQL). The current stable toolchain is Rust 1.96.0 on the 2024 edition; cargo new selects it automatically.

TypeScript/JavaScript Example

Here is a typical Node data-access layer. The first two functions are written the responsible way with the pg driver; the third is the trap that ships in real codebases.

1
import { Pool } from "pg";
2

3
const pool = new Pool({ connectionString: process.env.DATABASE_URL });
4

5
interface User {
6
  id: number;
7
  name: string;
8
  email: string;
9
}
10

11
// Parameterized: values go through $1, $2 — pg sends them out-of-band.
12
async function findByEmail(email: string): Promise<User | null> {
13
  const result = await pool.query<User>(
14
    "SELECT id, name, email FROM users WHERE email = $1",
15
    [email],
16
  );
17
  return result.rows[0] ?? null;
18
}
19

20
// String interpolation = SQL injection.
21
async function unsafeSearch(name: string): Promise<User[]> {
22
  // If `name` is `' OR '1'='1`, this returns EVERY row.
23
  // If it's `'; DROP TABLE users; --`, you've lost the table.
24
  const result = await pool.query<User>(
25
    `SELECT id, name, email FROM users WHERE name = '${name}'`,
26
  );
27
  return result.rows;
28
}

Two things to notice. First, the safe and unsafe versions look almost identical — the only difference is $1 + a params array versus a template literal. It is easy to reach for the template literal, especially when the query “feels” dynamic. Second, unsafeSearch compiles and passes a casual code review; nothing in JavaScript or TypeScript flags it. The type parameter <User> is unverified — TypeScript never checks that the SQL actually returns those columns.

Warning: Template literals are the single most common source of injection in Node code, because they make concatenation look clean. A backtick around SQL with a ${} inside is a red flag every time.

Rust Equivalent

SQLx closes both gaps. The value is passed via .bind(...), which the driver sends as a separate prepared-statement parameter — it never becomes part of the SQL text. Add the dependencies first:

1
cargo add sqlx --no-default-features --features sqlite,runtime-tokio,macros
2
cargo add tokio --features full

1
use sqlx::sqlite::SqlitePoolOptions;
2
use sqlx::{FromRow, SqlitePool};
3

4
#[derive(Debug, FromRow)]
5
struct User {
6
    id: i64,
7
    name: String,
8
    email: String,
9
}
10

11
async fn setup(pool: &SqlitePool) -> Result<(), sqlx::Error> {
12
    sqlx::query(
13
        "CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT NOT NULL, email TEXT NOT NULL)",
14
    )
15
    .execute(pool)
16
    .await?;
17

18
    for (name, email) in [("Alice", "alice@example.com"), ("Bob", "bob@example.com")] {
19
        sqlx::query("INSERT INTO users (name, email) VALUES (?, ?)")
20
            .bind(name)
21
            .bind(email)
22
            .execute(pool)
23
            .await?;
24
    }
25
    Ok(())
26
}
27

28
// Safe: the value is BOUND, never spliced into the SQL text.
29
async fn find_by_name(pool: &SqlitePool, name: &str) -> Result<Vec<User>, sqlx::Error> {
30
    sqlx::query_as::<_, User>("SELECT id, name, email FROM users WHERE name = ?")
31
        .bind(name)
32
        .fetch_all(pool)
33
        .await
34
}
35

36
#[tokio::main]
37
async fn main() -> Result<(), sqlx::Error> {
38
    let pool = SqlitePoolOptions::new().connect("sqlite::memory:").await?;
39
    setup(&pool).await?;
40

41
    let found = find_by_name(&pool, "Alice").await?;
42
    println!("lookup 'Alice' -> {} row(s)", found.len());
43
    for u in &found {
44
        println!("  {:?}", u);
45
    }
46

47
    // Classic injection payload passed as the *value*. Because it is bound,
48
    // it is compared as a literal string and matches nothing.
49
    let payload = "Alice' OR '1'='1";
50
    let attacked = find_by_name(&pool, payload).await?;
51
    println!(
52
        "lookup with payload {:?} -> {} row(s) (no leak)",
53
        payload,
54
        attacked.len()
55
    );
56

57
    Ok(())
58
}

Running it produces this real output:

1
lookup 'Alice' -> 1 row(s)
2
  User { id: 1, name: "Alice", email: "alice@example.com" }
3
lookup with payload "Alice' OR '1'='1" -> 0 row(s) (no leak)

The injection payload returns zero rows — exactly what we want. The driver compared the literal 16-character string Alice' OR '1'='1 against the name column. No row has that name, so nothing matches. The quotes inside the payload are just characters in a value; they never terminated a string literal because there was no string literal in the SQL to terminate.

Detailed Explanation

How a prepared statement neutralizes the attack

When you write WHERE name = ? and call .bind(name), two separate things travel to the database:

The SQL template — SELECT ... WHERE name = ? — which the server parses and plans once, with the ? as a typed slot.
The value — Alice' OR '1'='1 — sent afterward as binary protocol data that fills the already-parsed slot.

Because the query is parsed before the value arrives, there is no parsing step left for the value to subvert. Contrast that with format!("WHERE name = '{name}'"), where the value is part of the text the parser sees, so a stray quote changes the query’s structure. This is the entire game: parse first, fill values after.

`query` vs `query_as` vs `query!`

SQLx gives you three layers, all of which bind parameters the same way:

sqlx::query("... ?") — runs SQL, returns generic rows. Bind with .bind(...).
sqlx::query_as::<_, User>("... ?") — same, but decodes each row into a #[derive(FromRow)] struct.
sqlx::query!("... ?", value) and sqlx::query_as!(...) — macros that connect to a real database during cargo build, verify the SQL parses, check the columns exist, and confirm the bound-parameter and result types line up. A typo becomes a compile error.

The macros take their bind values as extra macro arguments rather than .bind(...) calls, but they are still bound parameters — you cannot smuggle an unparameterized value in. This is stricter than anything in the TypeScript world: Prisma’s $queryRaw tagged template parameterizes, but it does not check your SQL against the live schema at build time.

Compile-time checking needs a database URL

Because the macros talk to a real database at build time, they need to know where it is:

1
#[tokio::main]
2
async fn main() {
3
    // query! checks the SQL against a real DB at compile time.
4
    let _ = sqlx::query!("SELECT id FROM users WHERE id = ?", 1i64);
5
}

Building this without a DATABASE_URL set gives the real error:

1
error: set `DATABASE_URL` to use query macros online, or run `cargo sqlx prepare` to update the query cache
2
 --> src/main.rs:4:13
3
  |
4
4 |     let _ = sqlx::query!("SELECT id FROM users WHERE id = ?", 1i64);
5
  |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

In CI you either point DATABASE_URL at a throwaway database or commit a .sqlx query cache produced by cargo sqlx prepare so builds work offline. The non-macro sqlx::query(...) form needs no database at build time — it just gives up the compile-time checking. Both are equally safe against injection; the macro adds correctness checking on top.

Key Differences

Concern	TypeScript (`pg` / Prisma)	Rust (SQLx)
Safe binding	`pool.query(sql, [v])`; `$queryRaw\`…“	`.bind(v)` or `query!(sql, v)`
Placeholder syntax	`$1, $2` (pg)	`?` (SQLite/MySQL), `$1` (Postgres)
Easy to inject by accident?	Yes — template literals look clean	Harder — binding is the path of least resistance
SQL verified against schema?	No (`$queryRaw` is unchecked)	Optional, at compile time via `query!`
Result columns type-checked?	No (`<User>` is unverified)	Yes, with `query!`/`query_as!`
Identifiers (table/column) bindable?	No	No (same SQL limitation)

The conceptual point that surprises TypeScript developers: Rust does not make injection impossible — SQL is still a string and you can still call format!. What it does is make the safe path (bind) the natural, ergonomic one and offer compile-time SQL verification that no TypeScript tool matches. Discipline still matters; the language just tilts the floor toward safety.

Note: Bound parameters protect values, not identifiers. You can never bind a table name, column name, ORDER BY direction, or LIMIT keyword — that is a SQL-engine limitation shared by every language. Dynamic identifiers need an allowlist; see Common Pitfalls below.

Common Pitfalls

Pitfall 1: `format!` into SQL compiles perfectly

The most dangerous thing about injection in Rust is that the borrow checker will not save you here — building SQL with format! is valid Rust:

1
// VULNERABLE — compiles and runs, but is injectable.
2
async fn find_unsafe(pool: &sqlx::SqlitePool, name: &str) -> Result<(), sqlx::Error> {
3
    let sql = format!("SELECT id FROM users WHERE name = '{name}'");
4
    sqlx::query(&sql).fetch_all(pool).await?;
5
    Ok(())
6
}

There is no compiler error, no Clippy warning by default. If name is ' OR '1'='1, this leaks every row. Rule: if a user-controlled value ends up inside format!, +, or write! that builds SQL, you have a bug. Search your codebase for format!( near query( as a quick audit.

Pitfall 2: Trying to bind an identifier and being surprised it “doesn’t work”

Placeholders only stand in for values. This compiles and runs, but the sort does nothing useful:

1
// The `?` cannot be a column name; the DB binds it as a value and ignores it
2
// for ordering, so the rows come back in their natural order.
3
async fn order_by(pool: &sqlx::SqlitePool, column: &str) -> Result<(), sqlx::Error> {
4
    sqlx::query("SELECT id, name FROM users ORDER BY ?")
5
        .bind(column)
6
        .fetch_all(pool)
7
        .await?;
8
    Ok(())
9
}

Running order_by(&pool, "name") does not sort by name — the bound ? is treated as a constant value in the ORDER BY, which SQLite ignores. The fix is not to switch back to format! with the raw input; it is to use an allowlist (Best Practices below).

Pitfall 3: Forgetting `.await`, then misreading the error

SQLx query builders are lazy futures — nothing runs until you .await. Drop the .await and you get a type error, not a runtime hang:

1
async fn count(pool: &sqlx::SqlitePool) -> Result<i64, sqlx::Error> {
2
    // forgot `.await` on fetch_one
3
    let row: (i64,) = sqlx::query_as("SELECT COUNT(*) FROM users").fetch_one(pool);
4
    Ok(row.0)
5
}

The real compiler error:

1
error[E0308]: mismatched types
2
 --> src/main.rs:6:23
3
  |
4
6 |     let row: (i64,) = sqlx::query_as("SELECT COUNT(*) FROM users").fetch_one(pool);
5
  |              ------   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ expected `(i64,)`, found future
6
  |              |
7
  |              expected due to this

found future is the tell: add .await. This is unlike JavaScript, where a forgotten await silently yields a Promise that often “works” enough to mask the bug until later. See Futures are lazy for why.

Pitfall 4: Assuming an ORM means you are immune

Even with a query builder or ORM, the moment you drop to a raw-SQL escape hatch ($queryRawUnsafe in Prisma, sqlx::query with a hand-built string) you are back on the hook. Injection is about how the value reaches the engine, not which library you used.

Best Practices

Always bind values. Reach for .bind(...) or the query!/query_as! macros. Treat any format!/string-concatenated SQL that includes user input as a defect.
Use the compile-time-checked macros when you can. query!/query_as! catch typos, missing columns, and type mismatches at build time — a strict improvement over TypeScript’s unverified raw queries.
For dynamic identifiers, use an allowlist that maps user input to your own constant strings. Only literals you control ever reach the SQL:

1
use sqlx::sqlite::SqlitePoolOptions;
2
use sqlx::{FromRow, SqlitePool};
3

4
#[derive(Debug, FromRow)]
5
struct User {
6
    name: String,
7
}
8

9
// Map untrusted input to one of OUR OWN literals. The raw input never
10
// reaches the SQL — only a `&'static str` we hand-picked does.
11
fn safe_sort_column(input: &str) -> &'static str {
12
    match input {
13
        "name" => "name",
14
        "id" => "id",
15
        _ => "id", // default; reject or fall back, never echo user input
16
    }
17
}
18

19
async fn list_sorted(pool: &SqlitePool, sort: &str) -> Result<Vec<User>, sqlx::Error> {
20
    let column = safe_sort_column(sort);
21
    // `column` is one of our literals, so this interpolation is safe.
22
    let sql = format!("SELECT name FROM users ORDER BY {column}");
23
    sqlx::query_as::<_, User>(&sql).fetch_all(pool).await
24
}
25

26
#[tokio::main]
27
async fn main() -> Result<(), sqlx::Error> {
28
    let pool = SqlitePoolOptions::new().connect("sqlite::memory:").await?;
29
    sqlx::query("CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT)")
30
        .execute(&pool)
31
        .await?;
32
    sqlx::query("INSERT INTO users (name) VALUES ('Zed'), ('Amy')")
33
        .execute(&pool)
34
        .await?;
35

36
    let by_name = list_sorted(&pool, "name").await?;
37
    println!("sorted by name -> {:?}", by_name);
38

39
    // Attacker-supplied column is ignored; falls back to a safe default.
40
    let evil = list_sorted(&pool, "name; DROP TABLE users; --").await?;
41
    println!("evil sort input -> {:?} (fell back to id)", evil);
42

43
    Ok(())
44
}

Real output — the malicious input is discarded and the table survives:

1
sorted by name -> [User { name: "Amy" }, User { name: "Zed" }]
2
evil sort input -> [User { name: "Zed" }, User { name: "Amy" }] (fell back to id)

Apply least-privilege at the database layer too. The application’s DB role should not be able to DROP TABLE or read tables it doesn’t need. Defense in depth means even a missed bind cannot become a catastrophe.
Pair binding with input validation. Parameterization stops injection, but it does not stop a 10 MB “name” or an email that is not an email. Validate shape and bounds first — see Input Validation.

Real-World Example

A search endpoint almost always has optional filters: filter by role if one was given, restrict to active users if asked. The temptation is to build the WHERE clause with string concatenation. SQLx’s QueryBuilder lets you assemble dynamic SQL while every value still goes through push_bind, which appends a placeholder and binds the value — so the query stays injection-proof no matter which filters are present.

1
use sqlx::sqlite::SqlitePoolOptions;
2
use sqlx::{FromRow, QueryBuilder, Sqlite, SqlitePool};
3

4
#[derive(Debug, FromRow)]
5
struct User {
6
    id: i64,
7
    name: String,
8
}
9

10
async fn setup(pool: &SqlitePool) -> Result<(), sqlx::Error> {
11
    sqlx::query("CREATE TABLE users (id INTEGER PRIMARY KEY, name TEXT, role TEXT, active INTEGER)")
12
        .execute(pool)
13
        .await?;
14
    let rows = [
15
        ("Alice", "admin", 1),
16
        ("Bob", "user", 1),
17
        ("Carol", "user", 0),
18
    ];
19
    for (name, role, active) in rows {
20
        sqlx::query("INSERT INTO users (name, role, active) VALUES (?, ?, ?)")
21
            .bind(name)
22
            .bind(role)
23
            .bind(active)
24
            .execute(pool)
25
            .await?;
26
    }
27
    Ok(())
28
}
29

30
// Dynamic filtering done SAFELY: each user-supplied value goes through
31
// push_bind, which appends a placeholder AND binds the value.
32
async fn search(
33
    pool: &SqlitePool,
34
    role: Option<&str>,
35
    only_active: bool,
36
) -> Result<Vec<User>, sqlx::Error> {
37
    let mut qb: QueryBuilder<Sqlite> = QueryBuilder::new("SELECT id, name FROM users WHERE 1 = 1");
38
    if let Some(role) = role {
39
        qb.push(" AND role = ");
40
        qb.push_bind(role); // <- placeholder + bound value, not concatenation
41
    }
42
    if only_active {
43
        qb.push(" AND active = ");
44
        qb.push_bind(1);
45
    }
46
    qb.build_query_as::<User>().fetch_all(pool).await
47
}
48

49
#[tokio::main]
50
async fn main() -> Result<(), sqlx::Error> {
51
    let pool = SqlitePoolOptions::new().connect("sqlite::memory:").await?;
52
    setup(&pool).await?;
53

54
    let admins = search(&pool, Some("admin"), false).await?;
55
    println!("role=admin -> {:?}", admins);
56

57
    let active_users = search(&pool, Some("user"), true).await?;
58
    println!("role=user & active -> {:?}", active_users);
59

60
    // Even a malicious "role" is bound as a value, not SQL.
61
    let evil = search(&pool, Some("user' OR '1'='1"), false).await?;
62
    println!("evil role -> {} row(s)", evil.len());
63

64
    Ok(())
65
}

Real output:

1
role=admin -> [User { id: 1, name: "Alice" }]
2
role=user & active -> [User { id: 2, name: "Bob" }]
3
evil role -> 0 row(s)

The key line is qb.push_bind(role). It writes a placeholder into the SQL and stores the value to bind, exactly like the static ? case — only assembled at runtime. The structural keywords (AND role =) are your own constant strings via push; only values ever go through push_bind. The malicious role returns zero rows because, again, it is compared as a literal string. This is the pattern to reach for whenever you would otherwise be tempted to concatenate a WHERE clause.

Tip: Use push only for fixed SQL fragments you wrote yourself, and push_bind for every value. If you find yourself passing user input to push, stop — that is the concatenation bug in a new outfit.

Exercises

Exercise 1: Convert a vulnerable query

Difficulty: Beginner

Objective: Recognize and fix string-concatenated SQL.

Instructions: The function below builds SQL with format!. Rewrite it to use a bound parameter so the injection payload ' OR '1'='1 returns no rows. Assume a table products (id INTEGER PRIMARY KEY, sku TEXT).

1
async fn find_by_sku(pool: &sqlx::SqlitePool, sku: &str) -> Result<Vec<(i64, String)>, sqlx::Error> {
2
    let sql = format!("SELECT id, sku FROM products WHERE sku = '{sku}'"); // vulnerable
3
    sqlx::query_as::<_, (i64, String)>(&sql).fetch_all(pool).await
4
}

Solution

1
use sqlx::sqlite::SqlitePoolOptions;
2
use sqlx::SqlitePool;
3

4
// Bind the value; the `?` is filled by the driver, not by format!.
5
async fn find_by_sku(pool: &SqlitePool, sku: &str) -> Result<Vec<(i64, String)>, sqlx::Error> {
6
    sqlx::query_as::<_, (i64, String)>("SELECT id, sku FROM products WHERE sku = ?")
7
        .bind(sku)
8
        .fetch_all(pool)
9
        .await
10
}
11

12
#[tokio::main]
13
async fn main() -> Result<(), sqlx::Error> {
14
    let pool = SqlitePoolOptions::new().connect("sqlite::memory:").await?;
15
    sqlx::query("CREATE TABLE products (id INTEGER PRIMARY KEY, sku TEXT)")
16
        .execute(&pool)
17
        .await?;
18
    sqlx::query("INSERT INTO products (sku) VALUES ('A-100'), ('B-200')")
19
        .execute(&pool)
20
        .await?;
21

22
    let normal = find_by_sku(&pool, "A-100").await?;
23
    println!("A-100 -> {} row(s)", normal.len());
24

25
    let evil = find_by_sku(&pool, "' OR '1'='1").await?;
26
    println!("injection -> {} row(s)", evil.len());
27

28
    Ok(())
29
}

Real output:

1
A-100 -> 1 row(s)
2
injection -> 0 row(s)

Exercise 2: Safe dynamic sorting

Difficulty: Intermediate

Objective: Handle a user-chosen sort column without concatenating raw input.

Instructions: Write list_products(pool, sort_by) that orders results by "sku" or "id" based on sort_by. Any other value must fall back to "id". Confirm that passing "sku; DROP TABLE products; --" does not run any extra SQL and leaves the table intact.

Solution

1
use sqlx::sqlite::SqlitePoolOptions;
2
use sqlx::SqlitePool;
3

4
// Map untrusted input to one of our own literals — an allowlist.
5
fn sort_column(input: &str) -> &'static str {
6
    match input {
7
        "sku" => "sku",
8
        "id" => "id",
9
        _ => "id",
10
    }
11
}
12

13
async fn list_products(pool: &SqlitePool, sort_by: &str) -> Result<Vec<(i64, String)>, sqlx::Error> {
14
    let column = sort_column(sort_by);
15
    let sql = format!("SELECT id, sku FROM products ORDER BY {column}");
16
    sqlx::query_as::<_, (i64, String)>(&sql).fetch_all(pool).await
17
}
18

19
#[tokio::main]
20
async fn main() -> Result<(), sqlx::Error> {
21
    let pool = SqlitePoolOptions::new().connect("sqlite::memory:").await?;
22
    sqlx::query("CREATE TABLE products (id INTEGER PRIMARY KEY, sku TEXT)")
23
        .execute(&pool)
24
        .await?;
25
    sqlx::query("INSERT INTO products (sku) VALUES ('B-200'), ('A-100')")
26
        .execute(&pool)
27
        .await?;
28

29
    let by_sku = list_products(&pool, "sku").await?;
30
    println!("by sku -> {:?}", by_sku);
31

32
    let evil = list_products(&pool, "sku; DROP TABLE products; --").await?;
33
    println!("evil sort -> {:?} (fell back to id, table intact)", evil);
34

35
    Ok(())
36
}

Real output:

1
by sku -> [(2, "A-100"), (1, "B-200")]
2
evil sort -> [(1, "B-200"), (2, "A-100")] (fell back to id, table intact)

The malicious string never reaches the SQL — only the literal "id" does — so the table is never dropped.

Exercise 3: Optional filters with `QueryBuilder`

Difficulty: Advanced

Objective: Build a query with zero, one, or both optional filters where every value is bound.

Instructions: Write search_orders(pool, status, min_total) against a table orders (id INTEGER PRIMARY KEY, status TEXT, total INTEGER). Add AND status = ? only when status is Some, and AND total >= ? only when min_total is Some. Use QueryBuilder and push_bind so all values are bound. Verify that a malicious status returns no rows.

Solution

1
use sqlx::sqlite::SqlitePoolOptions;
2
use sqlx::{QueryBuilder, Sqlite, SqlitePool};
3

4
async fn search_orders(
5
    pool: &SqlitePool,
6
    status: Option<&str>,
7
    min_total: Option<i64>,
8
) -> Result<Vec<(i64, String, i64)>, sqlx::Error> {
9
    let mut qb: QueryBuilder<Sqlite> =
10
        QueryBuilder::new("SELECT id, status, total FROM orders WHERE 1 = 1");
11
    if let Some(status) = status {
12
        qb.push(" AND status = ");
13
        qb.push_bind(status);
14
    }
15
    if let Some(min_total) = min_total {
16
        qb.push(" AND total >= ");
17
        qb.push_bind(min_total);
18
    }
19
    qb.build_query_as::<(i64, String, i64)>()
20
        .fetch_all(pool)
21
        .await
22
}
23

24
#[tokio::main]
25
async fn main() -> Result<(), sqlx::Error> {
26
    let pool = SqlitePoolOptions::new().connect("sqlite::memory:").await?;
27
    sqlx::query("CREATE TABLE orders (id INTEGER PRIMARY KEY, status TEXT, total INTEGER)")
28
        .execute(&pool)
29
        .await?;
30
    for (status, total) in [("paid", 100), ("paid", 50), ("pending", 200)] {
31
        sqlx::query("INSERT INTO orders (status, total) VALUES (?, ?)")
32
            .bind(status)
33
            .bind(total)
34
            .execute(&pool)
35
            .await?;
36
    }
37

38
    let paid_big = search_orders(&pool, Some("paid"), Some(80)).await?;
39
    println!("paid & total>=80 -> {:?}", paid_big);
40

41
    let no_filters = search_orders(&pool, None, None).await?;
42
    println!("no filters -> {} row(s)", no_filters.len());
43

44
    let evil = search_orders(&pool, Some("paid' OR '1'='1"), None).await?;
45
    println!("evil status -> {} row(s)", evil.len());
46

47
    Ok(())
48
}

Real output:

1
paid & total>=80 -> [(1, "paid", 100)]
2
no filters -> 3 row(s)
3
evil status -> 0 row(s)

SQL Injection Prevention

Quick Overview

TypeScript/JavaScript Example

Rust Equivalent

Detailed Explanation

How a prepared statement neutralizes the attack

query vs query_as vs query!

Compile-time checking needs a database URL

Key Differences

Common Pitfalls

Pitfall 1: format! into SQL compiles perfectly

Pitfall 2: Trying to bind an identifier and being surprised it “doesn’t work”

Pitfall 3: Forgetting .await, then misreading the error

Pitfall 4: Assuming an ORM means you are immune

Best Practices

Real-World Example

Further Reading

Exercises

Exercise 1: Convert a vulnerable query

Exercise 2: Safe dynamic sorting

Exercise 3: Optional filters with QueryBuilder

`query` vs `query_as` vs `query!`

Pitfall 1: `format!` into SQL compiles perfectly

Pitfall 3: Forgetting `.await`, then misreading the error

Exercise 3: Optional filters with `QueryBuilder`