---
name: sql-injection-audit
description: Check repository code for SQL injection vulnerabilities. Use when creating, modifying, reviewing, or debugging code that builds or executes SQL queries.
SQL Injection Audit
---

# SQL Injection analysis

Use this skill when working with code that interacts with relational databases or constructs SQL queries.

## Core Rules

- Treat all external/user-controlled input as untrusted.
- Never concatenate or interpolate untrusted input directly into SQL.
- Prefer parameterized queries or prepared statements.
- Use ORM/query-builder parameterization when available.
- Do not rely on input sanitization or escaping as the primary defense.
- Review raw SQL and ORM escape-hatch APIs carefully.
- Validate dynamic SQL identifiers such as table names and column names with strict allowlists.
- Consider second-order SQL injection when user-controlled data is stored and later used in SQL.
- Do not consider tests passing as proof that SQL injection is impossible.

## Review Workflow

1. Identify SQL execution points:

- raw SQL;
- database driver queries;
- ORM raw queries;
- query builders;
- stored procedures;
- dynamically generated SQL.

2. Trace untrusted input into SQL:

- HTTP parameters;
- request bodies;
- headers;
- cookies;
- GraphQL inputs;
- CLI arguments;
- external API data;
- stored user-controlled data.

3. Look for dangerous patterns:

- string concatenation;
- template literals;
- dynamic WHERE clauses;
- dynamic ORDER BY;
- dynamic table/column names;
- raw SQL fragments;
- unsafe ORM APIs.

4. Verify the fix:

- confirm values are passed as SQL parameters;
- confirm dynamic identifiers use an allowlist;
- review relevant tests;
- run existing security/static-analysis tools when available.

5. Report findings with:

- severity;
- file and line;
- source of untrusted input;
- SQL sink;
- data flow;
- impact;
- recommended fix.
- Secure Pattern


## Completion Criteria

Before completing the task:

- Relevant SQL queries were reviewed.
- Untrusted input flows were checked.
- Raw SQL and ORM escape hatches were reviewed.
- Parameterization was verified.
- Dynamic identifiers were checked.
- Relevant tests were reviewed or run.
- Any SQL injection risk is explicitly reported.

If the requested change introduces SQL injection, stop and explain the vulnerability and recommend a parameterized or otherwise safe implementation.