ai-for-dummies/public/submitted-skills/Andre Salvo/skills/sql-injection-audit/SKILL.md

---

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.