SQL Injection: Beyond Parameterized Queries

What SQL injection actually is

SQL injection is usually taught as "the attacker put a quote in your input." That is the symptom. The cause is structural. Your application assembles a statement by concatenating a query template you wrote with data you did not, then hands the database one flat string. The parser then has to recover your intent from bytes, and it cannot, because nothing in that string marks where your trusted structure ends and the attacker's data begins. Code and data travel the same channel. Formally this is CWE-89, and it anchors the A05:2025 Injection category in the OWASP Top 10.

Every member of the injection family, OS command, LDAP, XPath, ORM/HQL, template injection, is this same collapse in a different interpreter, and prompt injection (which the closing section returns to) is the same kind of trust-boundary collapse again. The mental shift that pays off: stop hunting "dangerous characters" and treat the bug as two trust domains merged into one string.

Where it hides in real apps

The login form is where SQL injection is taught and almost never where it lives. Injection follows data, and data arrives from far more places than the obvious field. Any value that reaches a query is a candidate, no matter how trustworthy it looks:

• Request metadata, not just the body, headers, cookies, and path parameters. Documented cases include injection through the Host header and even fields lifted from a client TLS certificate.
• Structured bodies and APIs, JSON fields and the filter and sort grammars of GraphQL and OData resolvers, which routinely compile down to SQL. A typed GraphQL schema validates the shape of a request, not the safety of the resolver behind it: if that resolver still concatenates an argument into SQL, the endpoint is injectable like any other, and the type system has bought you nothing.
• Bulk and external inputs, CSV and file imports, third-party webhooks, and SSO/SAML/OIDC profile fields (display name, group, department) that you did not author and the identity provider did not sanitize for you.
• Upload and file metadata, the filename, object key, content-type, and archive entry names that ride along with an upload and then flow into queries through imports, document management, and admin search, long after the file itself was handled.
• Internal and deferred paths, admin and report builders that assemble queries from user choices, background jobs that process the data hours later, and stored data reused in a new query long after it was safely inserted (the second-order case).
• Generated SQL from natural language, the 2026 addition: LLM agents, analytics assistants, "ask your data" features, and text-to-SQL report builders that compose queries from untrusted instructions. It is query generation driven by attacker-influenceable input, a structural-query risk rather than just another input source, so it gets its own treatment under the footguns below.

The common thread is that none of these feel like attacker input at the point of use. A header looks like infrastructure, an SSO field looks like it came from a trusted provider, a row in your own database looks like your data. The query does not care where the bytes came from; if they were ever attacker-influenced, they still are when they reach the parser. So, no, it is not just login forms.

Modern query-feature footguns

"Parameterize values; allowlist structure" is the whole rule, but a surprising number of features blur the line between the two, and that blur is where careful teams still slip.

• LIKE wildcards. Binding a value into a LIKE still leaves % and _ active inside it. That is not classic injection, but it lets a user turn a prefix search into a full-table scan or match far more than intended. Escape them with a LIKE ... ESCAPE clause when they should be literal, and escape in the right order: the escape character you pick (\, !, whatever) must itself be doubled or escaped first, then % and _, or an attacker manipulates the escaping layer itself by feeding in the escape character. Even when escaped, treat broad search as an availability concern: cap the term length, reject pathological patterns such as a leading % wildcard that defeats the index, and route genuinely open-ended search to an indexed or search-specific path rather than letting a %term% scan the table. Keep collation in mind as well: under a case- or accent-insensitive collation, even a correctly escaped pattern can match more rows than the literal text suggests, so match behavior is a function of the column's collation, not just the escaping.
• LIMIT and OFFSET. Some drivers will not bind these, so people interpolate them. They are values: coerce to integers and bind or clamp, never concatenate raw. Be strict about the range while you are at it: reject negative LIMIT or OFFSET, reject absurd values, and reject anything outside the driver and database integer range, since both negatives and overflow can throw errors or behave surprisingly per engine. They are also an availability footgun even when bound, since a huge OFFSET forces the engine to count and discard millions of rows: clamp the maximum limit and prefer keyset (seek) pagination so an attacker cannot demand expensive deep scans. Deep pagination usually drags two other costs along with the offset: a full ORDER BY sort of the result set and a COUNT(*) for the total, both of which get expensive at scale, so cap or approximate the count and make sure the sort is index-backed rather than letting either run unbounded. One specific trap drives teams to give up and concatenate: with PHP PDO's emulated prepares on, a bound integer is sent quoted (LIMIT '10'), MySQL rejects it as a syntax error, and people conclude "you cannot bind a LIMIT" and splice it in raw. You can bind it: pass it with PDO::PARAM_INT, or turn emulation off, and the quoting goes away.
• JSON path and full-text expressions. JSON path strings (jsonb_path_query, JSON_EXTRACT) and full-text builders (to_tsquery, MATCH ... AGAINST) have their own little grammars; a user-supplied path or query concatenated in is injection into that grammar, not the value slot. JSON paths carry an availability footgun even when they are not injected: recursive descent and broad array wildcards can fan out into a denial of service over large documents, so limit the path depth and reject open-ended wildcards on user-supplied paths. For PostgreSQL search text, prefer plainto_tsquery or websearch_to_tsquery, which are intended for plain user input, over to_tsquery, which expects and trusts query syntax. They are the safer choice, not a free pass: still cap length, set a timeout, and design the search sanely so a valid-but-expensive query cannot become a denial of service. Decide deliberately which mode you are offering: plain user search (the websearch/plain functions) for normal users, and, only if you actually intend to expose advanced operators, treat that as a separate mini-language with its own allowlist of permitted operators and its own limits, rather than letting raw query syntax through under the banner of "search." The commonest form is interpolating the key itself into a ->> or -> accessor, which feels safe because it sits inside a JSON operator; the key is a value, so bind it:

  # vulnerable: the JSON key is concatenated into the query text
  cur.execute(f"SELECT * FROM events WHERE payload->>'{user_key}' = 'fail'")
  # safe: the key is a value (or use jsonb_extract_path_text(payload, %s))
  cur.execute("SELECT * FROM events WHERE payload->>%s = 'fail'", (user_key,))

• Type coercion that defeats an index. A value's type is an availability and correctness footgun even when it is safely bound. Compare an indexed VARCHAR column against a number, WHERE phone = 123456789, and MySQL converts the whole column to a number to do the comparison, which abandons the index and forces a full-table scan: an application-level denial of service from a single well-typed request. The same implicit conversion is a logic trap too, since in MySQL 'anything' = 0 is true, so a numeric comparison against a string column can match rows it never should. Match the bound value's type to the column, and reject input that does not fit the column's type before it reaches the query.
• Regex and SIMILAR TO. User-controlled patterns can inject regex operators, trigger catastrophic backtracking (a denial of service), or smuggle SQL-pattern syntax through SIMILAR TO. The practical defense is mostly avoidance: do not expose arbitrary regex where a substring or full-text search would do. Where you genuinely need it, cap pattern length, compile with a timeout where the engine supports one, reject nested quantifiers (the (a+)+ shape that drives backtracking), and prefer an engine with predictable, linear-time matching (RE2-style) over a backtracking one.
• Dynamic filter DSLs and report builders. The "build a query from the user's filters" feature is the richest footgun of all: field names, operators, sort, and grouping are all structure, all attacker-chosen, and none can be a bound value. Every one of those choices needs an allowlist mapping input to fixed, known-safe tokens, and operators should be allowlisted per field type, not globally, a date field gets ranges, a string field gets equality and prefix, never the reverse. And "structure" here is more than fields and operators: boolean grouping and nesting, joins, aggregates, GROUP BY and HAVING, and null semantics are all attacker-chosen structure too, each needing its own allowlist, plus a cap on overall depth and complexity so a filter tree cannot nest its way into an unbounded or ruinously expensive query. Make those allowlists authorization-aware, not merely syntactically safe: a field, join, aggregate, or relationship can be perfectly valid SQL and still expose data the current role or workflow should never see, so the allowlist has to encode who may query what, not just what parses.

The tell is the same every time: if the user controls a name, an operator, or a pattern's grammar rather than a plain value, binding does not save you. To be precise, the bind still does its job, it stops injection into the SQL parser; what it cannot stop is injection into a secondary grammar riding inside the value, a regex, a JSON path, full-text query syntax, or a filter DSL. That grammar needs its own defense. Constrain it to a set you defined.

Beyond the request: bulk imports, ETL, and cloud warehouses

Most of the channels above are request-driven, but a large share of an application's SQL is built far from any web handler, in code that reads files, moves data in bulk, and runs analytics. Those paths are the ones nobody fuzzes, and they tend to run with broad privileges, which is exactly why they are worth naming on their own.

Bulk, ETL, and import paths

Generated COPY and LOAD DATA statements, CSV-to-SQL loaders, warehouse ingestion jobs, admin import mappers, and background enrichment all tend to build SQL from data they do not control: file contents, column headers, sheet names, or a field mapping the user uploaded. It is second-order injection by construction, the bytes were written earlier, sometimes by a different system, and the unsafe statement is built when they are read back, often by a privileged batch role with file access. The fixes are the ones from Level 1 with a bulk-specific edge: move the row data through the driver's native bulk path rather than building statements out of it, a static COPY FROM STDIN command with the rows streamed and driver-encoded over the copy protocol (not SQL bind parameters), a prepared multi-row insert with bound values, or a real bulk-load API, never a string-built INSERT; treat headers and user-supplied column mappings as untrusted structure that must resolve through an allowlist of real columns, never reflect a spreadsheet header straight into an identifier; and run each import and reporting job under its own least-privileged role rather than the broad account the app already uses.

Cloud warehouses and analytics engines

The cloud data warehouse is the other modern surface, and it changes what injection buys. Snowflake, BigQuery, Redshift, Databricks SQL, and the BI query builders layered on top rarely hand an attacker an OS shell, but injection there converts into a different blast radius: cross-database and cross-dataset reads; external-stage and object-storage abuse (COPY INTO, UNLOAD, or EXPORT DATA to an attacker-controlled or attacker-readable destination the warehouse role or storage integration is permitted to write); misuse of the cloud identity the warehouse runs as (the attached IAM role, service account, or storage integration, which usually reaches far more than the current query); stored-procedure and UDF abuse (JavaScript and Python UDFs, external functions, and EXECUTE IMMEDIATE dynamic SQL); and bulk export of entire tables. BI tools deserve special caution: a report builder that assembles SQL from user-chosen dimensions, filters, and sorts is a dynamic filter DSL at warehouse scale, and the allowlist-the-structure rule applies unchanged. Defend it like any other database plus the cloud-native layers: bind values (major warehouse APIs and drivers support bind variables or parameter markers for values, with driver and statement-context exceptions), allowlist identifiers and dataset, schema, and stage names, scope the warehouse role and its attached cloud identity to least privilege, restrict external stages and network egress, lock down UDF and external-function creation, and enforce row-access policies and column masking so a query that does get through still cannot cross the datasets or columns it was never meant to see. One rule deserves to be explicit: never accept a user-supplied bucket, stage, URI, or export destination. Map a requested destination to a workflow-scoped, preapproved external location or storage integration, so an injected COPY INTO or EXPORT DATA has nowhere to send the data even if it runs.

Generated SQL: when a model writes the query

The hardest case of all is when a model writes the query. The whole statement is structure you did not author, so the footgun is not one feature but the entire SQL surface. The strongest move is to not let the model emit arbitrary SQL at all: have it produce constrained JSON or an intent object that a deterministic query builder compiles into SQL, because validating a narrow internal DSL you defined is far easier than validating arbitrary SQL after the fact.

Where you must accept generated SQL, make the dangerous things impossible rather than discouraged. A read-only role is the floor, not the ceiling: pair it with a read-only transaction and read-only session settings, and revoke temp-object privileges where the engine supports it, so the sandbox cannot write, run DDL, or create temporary objects, which are a sneaky write and side-effect surface even when permanent DDL is already denied.

Then gate the statement, and make that gate dialect-specific and recursive: parse with the target engine's grammar, require exactly one statement, and inspect every subtree. A shallow "is it a SELECT?" check sails right past dangerous function calls, CTEs, subqueries, lateral joins, hidden table references, comments, stacked statements, and vendor-specific syntax. Reject anything the DSL does not explicitly need. The AST check is the primary gate; query-plan inspection of touched tables, functions, and row estimates is a supplemental, engine-specific add-on. Order matters: run the AST and function allowlist before the SQL ever reaches the planner. Planning is not free of consequences, it resolves and discloses object and schema metadata, and on some engines or configurations it can invoke planner-time functions, rewrite rules, or hooks, so handing un-vetted model SQL even to a non-executing plan is not automatically safe. When you do inspect a plan, use a non-executing one, plain EXPLAIN under the sandbox role, never EXPLAIN ANALYZE or anything that actually runs the query.

Allowlist deliberately and deny by default, not just "no writes": permit only specific tables, columns, joins, operators, and callable functions, since a read-only role can still invoke expensive, leaky, or side-effecting functions depending on the engine and config. Block the control surface too, not only data changes: FOR UPDATE and LOCK TABLE, advisory locks, SET, transaction-control commands, and optimizer hints have no business in a generated read query, so reject them rather than assuming "read-only" already covers them.

Enforce row and tenant policy in the database underneath all of it, and cap output. Remember the slower exfiltration path: even with per-query output capped, an agent can page through and summarize sensitive rows across many turns, so the policy also has to bound the conversation or session budget, repeated paging over the same data, and what the model is permitted to reveal, not just the size of one result.

Mind what your rejections say, as well. A detailed "unknown column x in table y" or "policy z blocked this" hands the model, or whoever is steering it, a free map of your schema and rules. Log the rich reason internally and return a bland error outward. And keep human approval in its place: it is for exceptional, policy-permitted workflows, not the control that stands between a generated DROP and your data; the app role should make that statement unrunnable in the first place.

The escape hatches, by framework

Every ORM and query builder binds values for you on its normal path, and every one ships a raw escape hatch that does not. The rule is the same across all of them: stay on the typed API, and when you genuinely need raw SQL, bind through it rather than interpolating. The middle column is what to grep for in review; the last column is the correct way to use raw SQL when you must.

Containment architecture: assume one gets through

Parameterization is the control; containment decides what a missed one costs. "Least privilege" is the headline, but in practice it is an architecture, not a single GRANT.

• A role per app, service, and workflow. One shared, broadly privileged login means any injection anywhere reaches everything. Separate roles scope each blast radius to the job that owns it, and let a reporting or import path run with its own limited rights.
• Separate ownership from runtime. The role the app connects with should not own its tables. Run migrations as a distinct owner or deployer role, and revoke CREATE on schemas the app has no reason to extend. After least privilege itself, separating the owner from the runtime role is one of the biggest practical containment wins.
• Harden SECURITY DEFINER functions. They execute with the definer's rights, so a vulnerable one is an escalation path, especially when it references objects by unqualified name: if an attacker can create a shadow object in an earlier schema on the search_path, the function resolves to theirs and runs it as the definer. Schema-qualify the objects inside such functions, revoke schema CREATE so shadow objects cannot be planted, and explicitly set search_path to the trusted schemas with pg_temp last. Do not rely on omission: temp schemas can still be searched ahead of normal ones for relation and type names, so leaving pg_temp out is not the same as making it safe. Qualified names plus an explicit path are what actually close the shadowing window. And treat dynamic SQL inside a definer function as doubly dangerous, since it runs with elevated rights: bind every value (EXECUTE ... USING), allowlist any identifier, never build an object name from a caller-supplied string, and use safe identifier formatting (format('%I', ...), quote_ident) where a name truly must vary.
• Read-only by default. Most endpoints only read. Give them a role that cannot write, and an injection on a read path cannot tamper or drop. Read-only is not inert, though: a role that can still execute side-effecting functions, unsafe definer functions, or extension functions has more reach than its name implies, so revoke EXECUTE on the functions and packages the app does not actually call, and set default privileges so newly created functions are not executable by the app role by accident, otherwise the next migration quietly re-opens the gap. Revoking from the app role is only half of it: audit what the role inherits, especially PostgreSQL's habit of granting EXECUTE to PUBLIC on new functions, which the app role gets for free unless you revoke it from PUBLIC and adjust default privileges. Mind overloads and schemas while you are at it: revoking one function name does not cover its other overloaded signatures, and an unsafe function sitting in a trusted, on-path schema is as dangerous as a direct table grant. As a default, write functions SECURITY INVOKER (run as the caller) and reserve SECURITY DEFINER for the few that genuinely need elevated rights.
• Views that hide sensitive columns. OWASP calls these out specifically: expose each workflow or app role only to a view that omits password hashes, tokens, and PII, and even a successful SELECT * through injection cannot reach the columns you withheld. Scope it per role, the auth path that genuinely needs the hash can reach it through its own narrower role or a dedicated function, while the rest never can. A view only contains anything if the app role cannot also reach the base tables directly, so revoke the role's direct grants on the underlying tables and expose only the view or API surface intended for it, otherwise an injection just queries around the view. It reduces the blast radius rather than eliminating it, the projected rows may still hold regulated or business-sensitive data, so treat views as one containment layer, not a guarantee that a leak is harmless. In high-sensitivity PostgreSQL designs, mark such views security_barrier so a leaky or cleverly chosen user function cannot have its predicate pushed past the view's own filtering. Watch view ownership when combining views with RLS, too: a view runs with its owner's privileges by default, so it is the view owner's privileges that determine whether RLS on the underlying tables is applied or bypassed, not the calling role's; use security_invoker views (on supported PostgreSQL versions, 15 and later) for the cases where you intend the querying role's policies to be enforced.
• Encrypt or tokenize the highest-value fields, with keys the database cannot reach. For the data a leak would hurt most, secrets, tokens, payment and identity fields, store ciphertext or a surrogate token and keep the keys in a KMS or a separate service, so a successful read returns opaque bytes rather than plaintext, and decrypt only through narrow, audited application workflows that genuinely need it. The caveat is what does not count: transparent database encryption (TDE) protects files at rest, not query results, and any scheme whose keys are reachable by the injected database role, decryption done in the database, a key sitting in a table, a UDF that unwraps it, leaves the blast radius unchanged, because the attacker's query can decrypt exactly as the application does. The protection only holds when the key lives somewhere the injected query cannot follow.
• Tenant isolation with row-level security. In multi-tenant systems, enforce the tenant boundary in the database, not just the query. PostgreSQL's row-level security attaches a policy to every row, so an injected OR 1=1 still cannot cross tenants: the engine filters by policy regardless of the WHERE clause the attacker wrote. It only holds when it is set up correctly, though, enable it on every protected table, keep the runtime role a non-owner that is not a superuser and lacks BYPASSRLS, and use FORCE ROW LEVEL SECURITY where the owner or deployer role may query through the same path (policies otherwise do not apply to a table's owner; it is not always required when the app role is already a non-owner). Get the setup wrong and it is decorative; get it right and it holds even when the query does not.
• Cover writes, not just reads. A USING clause filters which rows a query can see, but it takes a WITH CHECK clause to stop an injected INSERT or UPDATE from creating a row in, or moving one into, another tenant. Without it the read side is contained while the write side leaks, which matters precisely because injection threatens integrity, not just confidentiality.
• Mind permissive versus restrictive policies. Multiple permissive policies are combined with OR, so each one only ever widens access: a single accidental broad permissive policy can quietly undercut the whole tenant boundary. Use restrictive policies (combined with AND) for the invariants that must always hold, but remember they only narrow access, they never grant it: at least one permissive policy still has to allow the row, so a table with only restrictive policies returns nothing. Review the full set of policies on a table together, not one at a time.
• RLS does not cover helper functions. Policies do not protect you from functions that intentionally expose protected rows or run with elevated rights, so audit any SECURITY DEFINER function that touches tenant-scoped tables, it can hand back exactly the rows the policy was meant to hide.
• Tenant context and connection pools. RLS is only as trustworthy as the tenant context it reads. A policy keyed on a session variable like current_setting('app.tenant_id') can be subverted if an injection stacks a SET, or if a pooled connection silently reuses the previous request's value. The strongest forms are per-tenant database roles where practical (they can be operationally heavy past a few thousand tenants), or, more commonly at scale, SET LOCAL inside a transaction with multi-statements disabled and the connection-pool reset verified so context never leaks between requests. Whichever you choose, the policy must fail closed: if app.tenant_id is missing, malformed, or unset after a pool reset, it should return no rows or raise, never fall back to a default tenant or broad access. That silent fallback is the quiet failure mode in app-set session-variable RLS, and it converts a missing variable into a cross-tenant leak. Mind the pooler mode, too: transaction-pooling setups (PgBouncer and the like) can break assumptions about session variables, prepared statements, and reset behavior. SET LOCAL inside an explicit transaction is the right direction, but it only holds if the pooler preserves that transaction boundary rather than multiplexing the statements across backends.

The mechanics above are PostgreSQL's, because it exposes the most of this surface in the open, but every major platform has direct equivalents. Map them across before assuming a control is Postgres-only:

One caveat on the masking column: masking is not encryption and not a substitute for revoking access to the base objects. Depending on the platform and the grants, a role with broad or ad hoc query privileges can often infer or bypass masked values, so treat masking as a presentation-layer control on top of real access revocation, not as the boundary itself.

Each layer holds even when the code does not. Containment starts from the assumption that a query will be built wrong some day, and arranges things so that day is survivable.

Proving you actually did it

Writing the defense is one thing; proving on demand that it is real, and stays real, is another. A verification program for injection has a few moving parts:

• Code review with a pattern in mind. Treat string-built SQL as guilty until proven innocent, and require that every dynamic-SQL exception names the allowlist that justifies it. "Why is this concatenated?" should have a written answer in the diff. The structural fix is to centralize query construction: route raw and dynamic SQL through a small set of helpers where binding, allowlists, logging, and tests are enforced once, so review has a handful of files to watch instead of every call site. Make it stick with the inverse rule: a lint or CI policy that forbids ad hoc raw SQL anywhere outside those helpers, otherwise centralization is aspirational and drifts back to scattered call sites. That policy should be a rule, not a wiki page. The Semgrep starting point below fails any f-string or concatenated SQL built outside the reviewed helpers; the convention it assumes is that all such code lives under a db/ package, so point the exclude path at wherever yours actually lives:

  # Semgrep (starting point): ban ad hoc raw SQL outside the reviewed db/ helpers
  rules:
    - id: raw-sql-only-in-db-helpers
      languages: [python]
      severity: ERROR
      message: >
        Dynamic SQL built by f-string/concat must live in the reviewed db/
        helpers, where binding and allowlists are enforced once.
      paths:
        exclude: ["**/db/**", "**/tests/**"]
      patterns:
        - pattern-either:
            - pattern: $CUR.execute(f"...", ...)
            - pattern: $CUR.execute("..." + $X, ...)
            - pattern: $CUR.execute("...".format(...), ...)

• Review migrations like code. The containment above lives in schema and grants, so changes to it deserve the same scrutiny as application code. Treat GRANT and REVOKE, CREATE EXTENSION, SECURITY DEFINER, RLS policy edits, and changes to ownership, schema, or default privileges as security-relevant diffs that a reviewer signs off on, since one loose grant or a dropped policy in a migration silently dismantles a control you carefully built.
• Static analysis in CI. Semgrep, CodeQL, and commercial SAST trace taint from a request into a query sink. Fail the build on the signal you trust, high-confidence taint rules and any new or changed dangerous sink in the diff, and route the noisier findings to triage rather than blocking on them. A gate calibrated this way gets respected; one that fails on every false positive gets disabled. A taint rule you trust looks like this, request data reaching the SQL text of execute(), with numeric coercion and an allowlist lookup treated as sanitizers so they do not trip it (tune the sources and sanitizers to your framework, and run it alongside Semgrep's maintained registry rules, not instead of them):

  # Semgrep (starting point): request data reaching the SQL text of execute()
  rules:
    - id: tainted-data-into-sql-string
      languages: [python]
      severity: ERROR
      mode: taint
      message: >
        User input flows into the SQL text of execute(). Pass it as a bound
        parameter (placeholder + value), not by concatenation or f-string.
      pattern-sources:
        - pattern: flask.request.args.get(...)
        - pattern: flask.request.form.get(...)
      pattern-sanitizers:
        - pattern: int(...)              # numeric coercion
        - pattern: $ALLOW.get(...)       # allowlist lookup returns a trusted token
      pattern-sinks:
        - patterns:
            - pattern: $CUR.execute($SQL, ...)
            - focus-metavariable: $SQL   # the query text only, bound params are safe

  That $ALLOW.get(...) sanitizer is only safe when the map is static and trusted and a miss is rejected before the query is built; a lookup that can return attacker-influenced text, or that falls through to the raw value on a miss, would silently suppress real findings. Both snippets are Python, since Semgrep rules are per-language, but the same source-to-sink shape ports to the equivalent escape hatches in JS, Java, PHP, and Ruby.
• Grep as a cheap backstop. Even a CI grep catches most of the danger: search for raw, literal, whereRaw, .extra(, EXEC(, and f-strings or + concatenation next to SELECT/INSERT/UPDATE. Each hit is a place to confirm a bind or a named allowlist. Add the framework escape hatches to the list: $queryRawUnsafe (Prisma), text() and literal_column (SQLAlchemy), .query( (TypeORM), ${...} (MyBatis), DB::raw (Laravel), find_by_sql and Arel.sql (ActiveRecord), and interpolated SQL in Dapper. Grep sp_executesql too, but treat it as a review target rather than a finding: it is the safe SQL Server pattern as long as the statement is static and the values are passed as parameters instead of concatenated into the string. Treat the whole list that way, in fact, every hit is a place to look, not a confirmed bug. Several entries (text(), DB::raw, Arel.sql) are perfectly safe when fed bound parameters and trusted, static fragments; the grep finds the conversations to have, and the review decides which are real. Extend the same grep to the bulk and warehouse paths, which app-layer patterns miss: COPY, COPY INTO, LOAD DATA, BULK INSERT, UNLOAD, EXPORT DATA, EXECUTE IMMEDIATE, copy_expert, and references to a stage or external location, then confirm each builds its statement and its object names from constants and allowlists, not from file contents or request input.
• Unit and property tests for the allowlist layer. The structural defenses, query builders, sort handlers, and filter DSLs, are code you can test directly. Feed them malicious field names, unexpected operators, and bogus sort directions, and assert that each is rejected or mapped to a known-safe token. That proves the allowlist itself, the part SAST and DAST struggle to reason about, and pins the behavior so a later refactor cannot quietly loosen it.
• Dynamic testing and fuzzing. DAST, parameter fuzzing, and a controlled sqlmap run against staging prove the running app, not just the source, and catch the second-order and config-dependent cases SAST cannot see. Keep it responsible: only against systems you own, on staging rather than production, rate-limited, with destructive tests off unless they are explicitly planned. It only finds what it can reach: SQL injection often hides behind authentication, CSRF and session flows, multi-step forms, imports, and background jobs, so the run has to be authenticated and stateful, exercising those paths with seeded data rather than just hammering the public surface. For the second-order cases specifically, plant the bait: seed canary payloads through imports, profile fields, and webhooks, then exercise the features that later reuse that stored data, reports, background jobs, notifications, exports, and admin views, and watch for the payload firing downstream. That is how you catch the read that was built unsafely long after the write that looked fine. Use out-of-band canaries as well as payload canaries: point a staging DNS or HTTP callback domain at your own collector and watch for blind hits, which safely surfaces the blind OOB paths, SSRF-style DB integrations, and UNC/SMB callbacks that return nothing in the response itself. Test the tenant boundary explicitly while you are in there: seed two tenants with canary rows and assert that no payload, from one tenant's session, can read or write the other's data. Cross-tenant leakage is exactly the failure RLS and tenant context are meant to prevent, and it is the one a generic scanner will not think to check.
• Fingerprint the generated SQL in staging. Log the queries your features actually emit, then assert their shape: when a test exercises a path, check that the SQL matches the expected template and uses bind markers rather than inlined literals. This is how you catch the "safe-looking UI path that quietly built raw SQL" bug before production, where neither a grep nor a type signature would have flagged it. Log the normalized template or fingerprint, not the full SQL with bound values, otherwise the diagnostic itself becomes a sensitive-data sink; assert on the bind markers and the query shape, and keep retention and access to those logs tight. Watch specifically for literal inflation: a useful assertion is that the shape uses bind markers and does not inline high-cardinality request values into the SQL text, because a query can match the expected structure while still smuggling raw literals where parameters belong.
• Lock and test driver configuration. The defenses you rely on are often defaults, and defaults drift on upgrade: a driver or ORM bump can quietly flip emulated prepares, multi-statement support, escaping behavior, a raw-query API, or type binding. Pin those settings explicitly and add a test that asserts the dangerous ones are off so a routine upgrade cannot silently reopen a hole. Do not just read the config back, prove the behavior with integration tests against a real database: assert that a stacked statement is actually rejected, that emulation is off where you expect, and that a bound parameter is sent as a bind rather than inlined into the SQL text. That last one is hard to see from ordinary DB logs, since many systems render binds back inline for readability, so confirming it usually means driver or wire-protocol instrumentation, prepared-statement metadata, or a controlled test payload that would error if it were ever parsed as code. Config flags and runtime behavior drift apart, and it is the behavior that matters. Pin dependency versions too, but pair the pin with an intentional upgrade process and config regression tests, never-upgrading is its own security problem; the goal is upgrades that are deliberate and verified, not frozen.

Keep the line between the two environments clear: active exploitation tooling (sqlmap, fuzzers, injected payloads) belongs on staging. In production, verification is passive, telemetry, canaries, and rate and query-shape signals that flag an attack without becoming one. Do not point active scanners at production traffic or data.

Make one rule non-negotiable and most of this enforces itself: every piece of dynamic SQL must reference a named allowlist. If a query varies its structure and there is no allowlist next to it, that is the finding, before anyone even tries to exploit it.

When it happens anyway

MOVEit is the reminder that one missed query can mean full compromise, so the response plan matters as much as prevention. If you suspect SQL injection has been exploited, the checklist runs roughly:

• Preserve evidence first, where you safely can. Rotation and reboots wipe exactly the state an investigation needs. Before you start tearing things down, snapshot the web roots, application and database audit/query logs, the WAF, reverse-proxy, and CDN logs (often the only place the original HTTP parameter, encoding, body, cookie, or duplicated parameter survives, which you need to reconstruct the exploit), running process lists, active and unusual database sessions, filesystem timestamps, and cloud and network flow logs. Where it is safe to, take a database snapshot too, a volume or managed snapshot before any destructive cleanup, so investigators have a frozen copy to reconstruct what the attacker's queries did. A few minutes of capture is the difference between knowing what was taken and guessing. It only correlates if the clocks agree: without synchronized time across the WAF, app, database, proxy, and cloud logs, stitching the timeline back together gets mushy fast, so confirm time sync is in place before an incident, not during one.
• Isolate egress, then cut access. Block the database host's outbound network to stop exfiltration in progress, then rotate database and application credentials and kill active sessions; assume the connection string and any cached secrets are burned.
• Account for what the data itself unlocks. If the query could have reached password hashes, session tables, password-reset tokens, API keys, or OAuth refresh tokens, the breach is also a credential breach: invalidate sessions, force resets, and rotate the exposed keys and tokens as part of containment, not after. Stolen secrets are how a one-time read becomes ongoing access.
• Hunt for persistence. Inspect web roots for dropped shells, and review triggers, scheduled jobs, stored procedures, and any new or newly elevated database and admin users, the places a query-to-shell pivot leaves itself a way back. Check the "database to elsewhere" footholds too: database links, foreign servers, and linked servers; external data sources; saved credentials and proxy accounts; replication and CDC jobs; and any cloud integration credentials the instance holds.
• Check for integrity damage, not just theft. Injection writes as well as reads: look for unexpected UPDATE or DELETE activity, new admin accounts, changed roles or grants, modified stored procedures and triggers, and altered scheduled jobs. Tampering is easy to miss when everyone is focused on what leaked.
• Look for exfiltration. Check for unexpected outbound DNS and HTTP from the database host (the out-of-band channel), and read the query and audit logs for information_schema sweeps, UNION activity, and bulk reads. Do not forget the SMB path from the out-of-band discussion above: watch for outbound 445 / 139 and UNC callbacks, plus NTLM authentication events to unfamiliar hosts and any relay or hash-capture indicators, that is credential theft, not just data egress. Scope it beyond the primary, too: the same data often lives on read replicas and followers, in warehouses and data lakes, in ETL pipelines, object-storage exports, and BI and reporting layers, any of which the attacker may have reached or which simply widen what "exposed" means.
• Pull the database's own recovery evidence. Binlogs (MySQL), the WAL (PostgreSQL), and transaction logs answer "what actually changed and when" with more fidelity than application logs, and your point-in-time-restore window and backups are how you get back to a known-good state. Note their limit: these logs capture writes, not reads, so they tell you what was altered, not what was exfiltrated, that question is the audit and query logging from the exfiltration step, not the transaction log. Confirm both exist and reach back far enough before you need them, and rehearse it: a backup that has never been restored is hope, not recovery, so run restore drills so the path is known to work under pressure. Mind what a restore brings back, too: point-in-time recovery will faithfully reinstate the attacker's created users, jobs, and triggers if you restore to after they landed, so a restore has to be paired with persistence cleanup and secret rotation, or you recover the foothold along with the data. And confirm the injection path is actually patched before you reconnect normal egress and credentials, otherwise a freshly restored, clean system is re-exploited within minutes by the same queued scanner or actor that hit it the first time. Clean up downstream as well: tampered rows may already have propagated to caches, queues, search indexes, materialized views, reports, and warehouses, so restoring the database alone can leave the bad data living happily one hop away.
• Scope the exposure. Identify the vulnerable parameter and every path that shares it, and, if the flaw was in a third-party product, check vendor advisories and patch status, the MOVEit pattern, where the bug was in someone else's code running in your environment.
• Get ready for notification duties. With SQL injection the exposed data is often exactly what triggers contractual, privacy, or regulatory notification obligations. Preserve the evidence above for counsel and incident response, and use it to scope who and what must be notified; that determination is far easier when the logs and change history are intact. Scope integrity impact, not only data exposure: altered balances, changed roles or permissions, modified email addresses, or tampered audit records can trigger contractual or regulatory obligations even when you cannot prove a single row was exfiltrated.

None of this is possible after the fact unless the logging and egress controls were already in place. That is the real reason to build containment before you need it, not during the incident.

The whole thing on one card

If you keep one artifact from this piece, keep this. Each line is a section above, compressed to the thing you actually do. It is also on the downloadable fix-and-prevent cheat sheet if you would rather print it:

Why a 1998 bug still runs 2026's breaches

SQL injection is the rare class that is both completely understood and completely endemic. The reason is not ignorance of the fix. The headline cause is that the fix is "parameterize values," and real applications must vary query shape: sorts, filters, searches, reports, and generated queries. Those are the parts parameterization cannot reach. But the survival of the bug is also operational, as this article has traced: driver defaults that drift on upgrade, privileges that creep, background jobs and second-order paths nobody tests, generated SQL from a model, and verification that never reaches the authenticated paths where it hides. Those gaps are where injection survives, and they are also the corners cut under deadline.

Step back and SQL injection and prompt injection are the same boundary failure at different layers: trusted instructions and untrusted data sharing one channel. The difference is that databases handed us a real boundary, the prepared statement, that separates the two at the protocol level, and even with that boundary in hand the bug never went away, because it does not reach the parts of SQL that have to vary. The lesson carries straight into AI security: an enforceable boundary is the best thing a platform can give you, and it only protects the places you actually use it.

References and further reading

The specifics above are drawn from the standards bodies, primary documentation, and research that define and document this class. Worth keeping close:

• CISA / FBI advisory AA23-158A on the Cl0p exploitation of CVE-2023-34362 (MOVEit), including the LEMURLOOT web shell, the source for the MOVEit details here.
• Rain Forest Puppy (Jeff Forristal), "NT Web Technology Vulnerabilities", Phrack #54 (1998), the first public documentation of the technique now called SQL injection.
• Chris Anley, "Advanced SQL Injection in SQL Server Applications" (NGSSoftware, 2002), the foundational technical paper that mapped out exploitation depth.
• CWE-89 (SQL Injection) and OWASP Top 10 A05:2025 Injection, the canonical taxonomy.
• OWASP Top 10 for LLM Applications, LLM01:2025 Prompt Injection, the authoritative anchor for the generated-SQL risk and the prompt-injection parallel.
• OWASP cheat sheets: SQL Injection Prevention and Query Parameterization, plus the SQL Injection attack reference.
• PostgreSQL documentation: Row Security Policies and Writing SECURITY DEFINER Functions Safely, the primary source for the RLS and least-privilege containment above.
• OWASP Web Security Testing Guide: Testing for SQL Injection and Testing for NoSQL Injection, the methodology behind the verification section.
• PortSwigger Web Security Academy: the SQL injection labs and the DBMS-specific SQL injection cheat sheet, hands-on for the channels, dialects, and fingerprinting covered here.
• sqlmap, the open-source tool that automates the detection and exploitation path described under "Automated, and at scale."
• Justin Clarke, SQL Injection Attacks and Defense, 2nd edition (Syngress, 2012), the book-length treatment, broad and deep across databases, channels, and exploitation and defense techniques.
• Chris Shiflett, "Addslashes Versus mysql_real_escape_string", the classic write-up of the GBK multibyte escaping bypass.