---
author: 'Andre Salvo'
description:
  'Audit a changed code path for SQL injection. Use when code constructs or
  executes SQL, query-builder fragments, or ORM raw queries.'
extras:
  'Add an eval with a parameterized query and a dynamic `ORDER BY` allowlist.'
focus:
  'Trace user-controlled data to SQL sinks and verify values are parameterized.'
id: 'sql-injection-audit'
improve:
  - 'The frontmatter is invalid because an un-keyed line appears inside it; fix
    this first so hosts can discover the skill.'
  - 'Scope the audit to changed code or named paths by default to avoid an
    unbounded repository scan.'
  - 'Add language-specific safe/unsafe examples in a reference rather than
    expanding the main file.'
name: 'sql-injection-audit'
path: '../submitted-skills/Andre%20Salvo/skills/sql-injection-audit/SKILL.md'
status: 'Fix metadata'
title: 'SQL injection audit'
wins:
  - 'Strong threat-model coverage, including identifiers and second-order
    injection.'
  - 'The report asks for source, sink, and data flow.'
---

# sql-injection-audit

## Inputs

Changed files, branch diff, or a named query path.

## Workflow

1. Find SQL execution sinks and trace request, CLI, external, and stored user
   input to them.
2. Confirm values use driver or ORM parameters. For dynamic identifiers, confirm
   a finite allowlist maps a user choice to a trusted token.
3. Review raw-query escape hatches and stored procedures.
4. Report only evidenced findings with source, sink, location, impact, and a
   safe pattern.

## Rules

- Escaping is not a substitute for parameterization.
- Passing tests are supporting evidence, not proof of safety.
- Do not modify code unless the user asks for a fix.

## Output

Return a findings table and the scope reviewed; say explicitly when a path could
not be traced.