They assume the ORM protects every database call, even when developers drop into native SQL or manual connection handling. The risk returns the moment a query is assembled as text. Teams should therefore review low-level SQL paths separately and require the same parameter-binding standard there as in handwritten code.
Why ORM safety breaks the moment SQL leaves the ORM
An ORM is a safety layer only while it is actually generating and parameterising the query. Once code drops into native SQL, string concatenation, or ad hoc connection handling, the ORM no longer normalises the risk for you. At that point, the security posture depends on the same low-level disciplines as handwritten SQL: parameter binding, input handling, and review of the exact query text that reaches the database.
That distinction matters because teams often treat “we use an ORM” as a blanket control. In practice, ORM safety is conditional, not universal: the protection covers mapped queries, but it does not magically extend to every raw query path, stored procedure call, or helper that assembles SQL outside the ORM abstraction.
When developers reach for native SQL, the code path often becomes harder to inspect than the ORM path. Query construction moves away from the framework’s safer defaults, and the reviewer has to verify the boundary directly. That is why low-level database access should be treated as a separate trust boundary rather than a minor implementation detail.
What teams misjudge about parameter binding and review scope
The most common mistake is assuming the ORM’s use of parameters in one layer proves the whole application is safe. Native SQL can still be vulnerable even in an ORM-backed codebase if a query is assembled as text before it reaches the driver. The control has to be preserved at the exact point where values are bound to the statement.
Teams also under-review “exception” paths such as reporting queries, bulk operations, debug utilities, and direct connection code. Those paths often bypass the patterns that application teams trust most, which means they deserve explicit secure-coding checks rather than informal code review assumptions.
If a code path accepts user-controlled input and emits SQL text, it should be reviewed as if no ORM existed. That does not mean every raw query is unsafe, but it does mean the burden of proof shifts to the implementation: show the binding, show the escaping strategy where relevant, and show that the query shape cannot be changed by attacker input.
How to govern ORM and native SQL consistently
The practical control is consistency, not abstraction choice. Teams should define one standard for parameter binding, then enforce it across ORM-generated queries, native SQL, stored procedures, and manual connection code. The same review expectation should apply anywhere a statement is assembled or executed outside the ORM’s managed query builder.
For code review, that means looking for the exact query construction mechanism rather than the presence of an ORM dependency. A safe application can still contain unsafe database calls if one library helper, reporting endpoint, or migration script reintroduces text concatenation. The review question is therefore simple: does this path preserve parameterisation at the last mile?
For testing, it helps to separate “ORM coverage” from “SQL path coverage.” Teams should validate raw SQL paths with the same scrutiny they would apply to handwritten database code, because the attack surface is functionally the same once the statement is emitted as text. SAP SQL Anywhere Monitor hard-coded credentials (CVE-2025-42890) is a reminder that database-adjacent tooling can create serious exposure when teams assume the surrounding platform will protect them automatically.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP ASVS, CIS Controls v8 and NIST SP 800-53 Rev 5 set the technical controls, while ISO/IEC 27001:2022 defines the regulatory obligations.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V4 — API and Web Service | Native SQL often enters through application-facing data access paths that must preserve parameter handling. |
| V8 — Authorization | Unsafe native SQL can bypass intended access checks if query shape is altered. | |
| Recommendation — Verify database-facing request handling preserves parameter binding before SQL reaches the driver. Confirm each SQL path cannot expand data access beyond the intended authorization boundary. | ||
| CIS Controls v8 | CIS-16 — Application Software Security | The issue is a secure-coding failure in application database access paths. |
| Recommendation — Review raw SQL paths and enforce secure coding checks for all database calls. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Text-assembled SQL depends on untrusted input being controlled before execution. |
| Recommendation — Validate and constrain input before it can alter SQL statement structure. | ||
| ISO/IEC 27001:2022 | A.8.28 — Secure coding | The subject is a coding practice issue in database access implementation. |
| Recommendation — Apply secure coding rules to every SQL construction path, including native queries. | ||
Practitioner Guidance
What to verify: Identify every raw SQL path, including native queries, stored procedures, administrative scripts, and direct JDBC or driver calls, then confirm each one preserves parameter binding end to end. If the query text is built from variables before binding, treat it as a defect until proven otherwise.
Common mistake: Treating ORM adoption as evidence that SQL injection risk has been solved. The abstraction may reduce exposure in the default path, but it does not compensate for developer-written SQL that bypasses the framework’s guardrails.
Decision rule: If the database call is not generated and bound by the ORM, review it under the same secure-coding standard as handwritten SQL. If a team cannot show how the statement is parameterised, the safe assumption is that the control is incomplete.
Practitioner takeaway: The security boundary is not “uses an ORM” or “does not use an ORM,” it is whether the final SQL reaches the database as bound parameters rather than attacker-influenced text.