SQL query built with format!/concatenation
Part of Security, which counts for 30% of the overall score. When this check fires it deducts 8 points from that category, once per scan, no matter how many places it turns up.
What it detects
A format!/concatenation-built string is passed directly as the argument to an execute/query/query_as/prepare call (rusqlite/sqlx/postgres-style APIs), instead of binding values as parameters. This cannot prove the interpolated value is attacker-controlled, so it is kept at medium severity like the other injection heuristics in this engine.
Why it matters
A SQL string built with format!/concatenation and passed straight into an execute/query call means whatever produced the interpolated value is now part of the SQL text itself, not a bound parameter. If that value ever originates from user input, request headers, or another untrusted source, it can alter the query's meaning entirely (classic SQL injection): reading other users' rows, bypassing a WHERE clause, or worse depending on the database's feature set.
How to fix it
Use the query builder's parameter binding instead of building the string: with sqlx that is `sqlx::query!("... WHERE name = $1", name)` or `.bind(name)`, with rusqlite that is `?1`/named parameters passed as a separate params argument, with tokio-postgres/postgres that is `$1`/`$2` placeholders with the values passed as a slice. Every value that varies per call should be a bound parameter, never text spliced into the query string.
The paid report includes a ready-to-paste prompt for your AI coding agent for every check it finds, pointed at the exact findings from your scan. See pricing
Does your repo trip this check?
Paste a GitHub URL or drop a project folder. Scans run in your browser and take seconds.
Scan your repo