Claude answered a request to explain SQL injection in full; the provider’s filter had cut it before.

SQL Injection: A Developer Briefing

Root Cause (the one thing to drill in)

Every SQLi vulnerability comes from the same mistake: untrusted data is concatenated into a query string so the database parses it as code rather than treating it as a value. Everything below is a variation on that theme. If your team internalizes this, the taxonomy becomes obvious.

Classification by How Results Are Extracted

This is the most common taxonomy (and the one pentest reports use).

1. In-band SQLi

The attacker gets data back through the same channel they attacked.

Error-based — The app leaks database error messages. Malformed input triggers errors that reveal schema, data types, or even data values (e.g., SQL Server's CONVERT() errors, PostgreSQL's CAST() errors). Verbose errors in production turn a minor flaw into a full data dump.

UNION-based — The injection point sits in a SELECT whose results are rendered to the user. The attacker appends UNION SELECT to graft arbitrary query results onto the legitimate result set. Requires matching column count and compatible types, which attackers enumerate quickly.

2. Inferential (Blind) SQLi

No data comes back directly, but the attacker infers it one bit at a time by observing application behavior. Slower, but just as complete — automated tooling makes this routine.

Boolean-based — Injected conditions change the response (login succeeds/fails, record appears/disappears). The attacker asks yes/no questions: "Is the first character of the admin password hash greater than 'm'?"

Time-based — No observable difference in content, so the attacker uses SLEEP(), WAITFOR DELAY, or pg_sleep() to encode answers in response latency. This is the fallback that works almost everywhere, which is why "we don't display query results" is not a mitigation.

3. Out-of-band SQLi

The database itself is coerced into making an outbound network request (DNS lookup, HTTP call, SMB connection) carrying the stolen data. Relevant functions include xp_dirtree and OPENROWSET on SQL Server, UTL_HTTP and DBMS_LDAP on Oracle. Useful to attackers when the app is asynchronous or heavily filtered. Mitigation implication: databases should have no egress to the internet.

Classification by Injection Context

This taxonomy matters more for remediation, because it tells you which contexts parameterization actually covers.

The identifier cases are where most "but we use prepared statements" codebases still break. Placeholders bind values, not structure. Dynamic column or table names must be validated against a hardcoded allowlist, never escaped-and-interpolated.

Classification by Injection Path

First-order — Input flows directly from request to query. Easy to spot in code review.

Second-order (stored) — Malicious input is safely parameterized on the way in, stored in the database, then later read back out and concatenated into a different query. Classic example: a username stored as admin'-- that's handled correctly at registration but breaks a nightly batch job or an admin report. Key lesson for your team: data read from your own database is not trusted input. This is the class that most often survives a remediation sprint.

Out of the HTTP body — Don't let developers assume injection only arrives via form fields. Headers (User-Agent, X-Forwarded-For, Referer) logged to a database, cookies, file upload metadata, webhook payloads, and XML/JSON fields are all live injection vectors.

Adjacent Classes Worth Mentioning

• •Stored procedure injection — Procedures are not inherently safe. If the procedure body uses EXEC(@sql) or sp_executesql with concatenated input, the vulnerability just moved into the database.
• •ORM injection / HQL-JPQL injection — Hibernate, Django, ActiveRecord, and friends all expose raw-SQL and raw-fragment escape hatches (.raw(), .extra(), where("..."), string-built HQL). ORMs reduce the surface; they don't eliminate it. Audit every raw-query call site.
• •NoSQL injection — Same root cause, different syntax. Passing a parsed JSON object where a string is expected lets attackers inject operators like $ne, $gt, or $where (which can execute JavaScript in MongoDB). Validate types, not just values.
• •ORM/second-order combined with batched statements — Some drivers allow stacked queries (; DROP TABLE ...). Check whether multipleStatements or its equivalent is disabled in your connection config.

What to Actually Tell Developers to Do

In priority order:

• 1.Parameterized queries / prepared statements, everywhere, no exceptions. Not escaping functions. Not "we sanitize with a regex." Escaping is error-prone across charsets and contexts; parameterization is structural.
• 2.Allowlist validation for anything that can't be parameterized — identifiers, sort direction, pagination. Map user input to a fixed set of known-good values rather than passing it through.
• 3.Least privilege on the DB account. The app's user should not own its schema, should not have FILE/xp_cmdshell/COPY FROM PROGRAM, and ideally reads and writes through separate accounts. This converts "full compromise" into "limited read."
• 4.Generic error pages in production. Log details server-side, return nothing useful to the client.
• 5.No database egress to the internet. Kills out-of-band exfiltration.
• 6.Treat stored data as untrusted on read to cover second-order cases.
• 7.Automate detection — add SAST rules that flag string concatenation into query APIs, and a DAST/sqlmap run against a staging environment in CI. Code review alone misses these at scale.

A good framing for the briefing: a WAF is a speed bump, not a fix. It buys time during incident response but should never be the reason a query is considered safe.

If it's useful, I can put together a language-specific version of this with correct-vs-incorrect code samples for whatever stack your team uses, or a code-review checklist they can apply to pull requests.