Teams often say "we use an ORM" or "all access goes through stored procedures, so injection is impossible." Under what conditions is each claim false, and does the same reasoning carry over to document-database query languages?

## The invariant, restated Injection is possible wherever an interpreter receives structure and data through one channel and cannot tell which is which. The defence is that *structure comes from trusted code and values arrive through a path that cannot alter structure*. Every claim of the form "technology X makes injection impossible" should be tested against that sentence, not accepted on the technology's reputation. ## ORMs What an ORM genuinely gives you is that, for statements it generates from a typed model, the generated text is fixed by the mapping and the user's values are bound. That covers a large share of a typical codebase, which is why ORM-heavy applications really do have fewer injection defects. But it is a coverage claim, not a guarantee, and four escape hatches recur: 1. **Native/raw query APIs.** Every mature ORM offers one, because reporting and vendor-specific features demand it. Inside that call the ORM contributes nothing; it is string concatenation with extra steps. 2. **String fragments in the builder.** Interfaces that accept a condition as text (`where("status = '" + s + "'")`) or an ordering as text are pass-throughs. The surrounding builder is safe, the fragment is not, and reviewers relax because the call looks like ORM code. 3. **Injection into the ORM's own query language.** Object query languages such as JPQL or HQL are parsed by the ORM, so a concatenated fragment is injectable there too. The blast radius is different — typically no DDL and no stacked statements — but an attacker can still pivot across associations to read entities they are not entitled to, which is the exfiltration half of the classic threat. 4. **Shapes the API cannot bind.** IN-lists built by joining strings, LIKE patterns where the wildcards are not escaped separately from the quotes, and dynamic sort/filter columns — the identifier problem again. So the honest statement is: an ORM raises the floor and concentrates risk into a small, greppable set of call sites. Treat those call sites as security-relevant, review them, and lint for them. ## Stored procedures The common belief is that a procedure is a parameterised call, therefore safe. The call *interface* is indeed parameterised; the question is what the body does with those parameters. A body that runs a static statement referencing the parameters is safe for the same reason binding is safe. A body that constructs SQL text — `EXEC(@sql)` in T-SQL, `EXECUTE IMMEDIATE` in PL/SQL, `EXECUTE ... USING` in PL/pgSQL, `PREPARE`/`EXECUTE` in MySQL — by concatenating its arguments is exactly as injectable as the application would have been. Dynamic SQL inside procedures is common precisely because procedures are where teams put the flexible reporting logic. Two things make this worse than the application-side equivalent. First, privilege: procedures frequently execute with the definer's rights, so the injected statement runs as a more powerful principal than the calling service's own account, defeating the least-privilege mitigation you were relying on. Second, visibility: the source lives in the database rather than the application repository, so it escapes code review, secret scanning, static analysis and often version control. The mitigation is identical to the application case — use the engine's parameterised dynamic execution form (`sp_executesql` with typed parameters, `EXECUTE IMMEDIATE ... USING`) so values bind, and allowlist identifiers — plus running procedures with invoker's rights unless a specific escalation is intended. ## Document and other non-SQL query languages Dropping SQL does not drop the bug class; it changes its clothes. Two distinct forms appear. **Operator/structure injection.** Many document stores accept a query as a structured object where a field maps to either a scalar (equality) or an object (an operator). If a request body is deserialised straight into that query object, an attacker who sends `{"password": {"$ne": null}}` where a string was expected converts "equals this password" into "is not null", the direct analogue of `OR 1=1`. No string parsing occurred anywhere; the confusion is between a value and a structural node. The defence is therefore not escaping — there is nothing to escape — but *type enforcement*: assert the field is a scalar of the expected type before it is placed in the query, and never build a query by copying user-supplied maps wholesale. **Server-evaluated code.** Query features that evaluate an expression or script server-side reconstitute a full interpreter boundary and are injectable in the classic string sense; they should be disabled or never fed untrusted text. The same reasoning applies to LDAP filters, XPath expressions, template engines and any ORM-like layer over a graph query language: identify the interpreter, identify the channel the value takes, and ask whether that channel can express structure. ## The answer an interviewer wants Refuse the framing that a technology confers safety. State the invariant, then for each technology say where its assembly point is and what escapes it: ORMs — raw queries, string fragments, object-query-language concatenation, unbindable identifiers; procedures — dynamic SQL in the body, made worse by definer privileges and poor visibility; document stores — operator injection defended by type enforcement rather than escaping.