Detect and analyze SQL injection vulnerabilities in application code and database queries.
Use when you need to scan code for SQL injection risks, review query construction, validate input sanitization, or implement secure query patterns.
Trigger with phrases like "detect SQL injection", "scan for SQLi vulnerabilities", "review database queries", or "check SQL security".
Scan application source code for SQL injection vulnerabilities (CWE-89, OWASP A03:2021) by tracing user input from entry points through data flows into database query construction. Detect string concatenation, format string interpolation, and inadequate parameterization across raw SQL, ORM raw query methods, stored procedure calls, and dynamic query builders.
Prerequisites
Application source code accessible in ${CLAUDE_SKILL_DIR}/
Database query files, ORM models, and repository/DAO layers available
Framework and language identified (Django, Rails, Express, Spring, Laravel, ASP.NET, Go, etc.)
Database type known (MySQL, PostgreSQL, SQLite, MSSQL, Oracle) for syntax-specific detection
Write permissions for reports in ${CLAUDE_SKILL_DIR}/security-reports/
Instructions
Discover database interaction code: search for SQL keywords (SELECT, INSERT, UPDATE, DELETE, ) and ORM raw query methods (, , , ) across all source files.
EXEC
raw()
execute()
createNativeQuery()
$wpdb->query()
Identify input surfaces: map all user-controllable data entry points -- HTTP parameters, request bodies, URL path segments, headers, cookies, file uploads, and WebSocket messages.
Trace data flows: follow each input surface through the code to determine whether user data reaches a SQL query. Flag any path where input is not passed through parameterized query binding.
Detect vulnerable patterns:
String concatenation: "SELECT * FROM users WHERE id=" + userId
f-string/format interpolation: Python f-strings embedding variables directly into SQL strings
Template literals: `SELECT * FROM users WHERE id=${req.params.id}`
ORM raw queries without bindings: Model.objects.raw("SELECT * FROM t WHERE x='" + val + "'")
Classify each finding: assign CVSS 3.1 score, identify attack type (classic injection, blind boolean/time-based, UNION-based exfiltration, second-order/stored injection), and document exploitability (authentication required, network access).
Assess impact per finding: determine data exposure scope (authentication bypass, data exfiltration, data modification, OS command execution via xp_cmdshell or LOAD_FILE()).
Generate remediation code: provide parameterized equivalents for each vulnerable query. Use framework-idiomatic patterns -- %s placeholders for Python DB-API, ? for Node.js, $1 for PostgreSQL, named parameters for Spring JPA.
Recommend defense-in-depth measures: input validation (allowlists over denylists), stored procedures with parameterized calls, least-privilege database accounts, WAF rules, and ORM-only data access policies.
Produce the vulnerability report at ${CLAUDE_SKILL_DIR}/security-reports/sqli-scan-YYYYMMDD.md with per-finding severity, CWE-89 mapping, file path and line number, vulnerable code snippet, attack vector demonstration, and remediated code.
See ${CLAUDE_SKILL_DIR}/references/implementation.md for the detection pattern library. See ${CLAUDE_SKILL_DIR}/references/critical-findings.md for example vulnerability write-ups with attack demonstrations.
Output
Vulnerability Report: ${CLAUDE_SKILL_DIR}/security-reports/sqli-scan-YYYYMMDD.md with all findings classified by severity
Finding Details: per-finding file path, line number, vulnerable code, attack vector, CVSS score, and remediation code
Remediation Summary: parameterized query replacements grouped by language/framework
