Parameterize Sql Queries
Every SQL query that includes any data — user input, configuration, computed values, anything not a literal in the source — must use parameterised queries (prepared statements) where the SQL structure is fixed and the va…
$ prime install @security/rule-parameterize-sql-queries Projection
Always in _index.xml · the agent never has to ask for this.
ParameterizeSqlQueries [rule] v0.1.0
Every SQL query that includes any data — user input, configuration, computed values, anything not a literal in the source — must use parameterised queries (prepared statements) where the SQL structure is fixed and the values are bound by the driver. Building queries by string concatenation, string formatting, or template substitution is forbidden.
Loaded when retrieval picks the atom as adjacent / supporting.
ParameterizeSqlQueries [rule] v0.1.0
Every SQL query that includes any data — user input, configuration, computed values, anything not a literal in the source — must use parameterised queries (prepared statements) where the SQL structure is fixed and the values are bound by the driver. Building queries by string concatenation, string formatting, or template substitution is forbidden.
Checks
- Queries use the driver's parameter API:
db.query("SELECT … WHERE id = ?", [id]), notdb.query("SELECT … WHERE id = " + id). - ORM query builders are configured with parameter binding by default; raw SQL escapes only via the parameter API.
- Identifiers (table/column names) that genuinely vary at runtime are validated against an allow-list, not bound (parameter binding doesn't apply to identifiers).
- Stored procedures called by parameter, not assembled as a string and
EXEC-ed. - CI grep / SAST rule flags string concatenation directly into SQL strings.
Label
All SQL queries use parameter binding, never string concatenation
Loaded when retrieval picks the atom as a focal / direct hit.
ParameterizeSqlQueries [rule] v0.1.0
Every SQL query that includes any data — user input, configuration, computed values, anything not a literal in the source — must use parameterised queries (prepared statements) where the SQL structure is fixed and the values are bound by the driver. Building queries by string concatenation, string formatting, or template substitution is forbidden.
Checks
- Queries use the driver's parameter API:
db.query("SELECT … WHERE id = ?", [id]), notdb.query("SELECT … WHERE id = " + id). - ORM query builders are configured with parameter binding by default; raw SQL escapes only via the parameter API.
- Identifiers (table/column names) that genuinely vary at runtime are validated against an allow-list, not bound (parameter binding doesn't apply to identifiers).
- Stored procedures called by parameter, not assembled as a string and
EXEC-ed. - CI grep / SAST rule flags string concatenation directly into SQL strings.
Label
All SQL queries use parameter binding, never string concatenation
Label
All SQL queries use parameter binding, never string concatenation
Source
prime-system/examples/security-appsec/primes/compiled/@security/rule-parameterize-sql-queries/atom.yaml