Raw SQL

Expanded Definition

Raw SQL is a direct query string that bypasses an ORM’s abstractions, so the developer controls the exact database operation and the exact trust boundary. That makes it useful for complex joins, vendor-specific syntax, performance tuning, and operations an ORM cannot model cleanly.

The boundary that matters is not “SQL versus ORM,” but “safe static text versus untrusted input.” Raw SQL becomes risky when application data is concatenated into the statement, when dynamic identifiers are not constrained, or when parameter handling is inconsistent. The safest pattern is a fixed query shape with values bound separately.

Definitions vary in how broadly they use the term. Some teams use “raw SQL” for any hand-written query, while others reserve it for cases where ORM helpers are bypassed entirely. In practice, the security meaning is the same: once the query is hand-authored, the developer owns the injection surface and the privilege implications of that query.

Examples and Use Cases

Raw SQL appears whenever an application needs precise control over the database engine rather than the ORM’s default behavior.

• Reporting queries that join several tables, aggregate results, and sort or filter by database-specific functions.
• Bulk updates or maintenance jobs where a set-based statement is faster and safer than iterating through ORM objects.
• Vendor-specific features such as window functions, CTEs, upserts, or optimizer hints that the ORM does not expose cleanly.
• Security-sensitive lookups where the application must keep the query text fixed and bind only user-controlled values.

A common tradeoff is that raw SQL can improve clarity and performance while reducing framework protection. The query is often easier to reason about for a database specialist, but it is also easier to misuse if developers treat it like a string template instead of a structured database call.

Security Implications

The main security issue is sql injection, but the broader problem is that raw SQL shifts responsibility for query construction, escaping, and privilege scope back to the application team. A single unsafe concatenation can turn a read query into data disclosure, tampering, or destructive access.

Misuse also creates subtle failures beyond classic injection. Queries can expose more columns than intended, bypass ORM-level filtering conventions, or lock the application into overly broad database permissions because the code path is too flexible to constrain later. That increases blast radius when a bug is found.

OWASP API Security Top 10 is a useful adjacent reference because raw SQL often becomes dangerous at the boundary where application inputs are transformed into database access decisions. In practice, the safest pattern is to assume every dynamic value is hostile unless it is explicitly parameterised and every identifier is validated against an allowlist.

Security, Operational and Governance Implications

Raw SQL matters because it changes who owns control enforcement. With an ORM, some guardrails are automated; with hand-written SQL, the development team must maintain consistency across every query path, every refactor, and every new feature.

Operationally, that means teams need strong review discipline for query text, privilege design that matches the smallest required database scope, and careful testing for unexpected query shape changes. Governance is especially important in codebases where raw SQL is used selectively, because the highest-risk statements are often the least visible ones.

One practical observation is that raw SQL is often introduced for legitimate performance or expressiveness reasons, then quietly spreads into adjacent code paths. That makes query ownership, code review, and least-privilege database access part of the security model rather than secondary controls.

Risk and Threat Considerations

Raw SQL creates a clear attack surface when untrusted input can influence the final statement. The main threat is injection, but the risk also includes privilege abuse, unintended data access, and destructive queries that exceed the developer’s intent.

Failure mechanism: Attackers exploit string concatenation, weak identifier validation, or improperly bound parameters to change the meaning of a query. If the application runs with broad database privileges, the injected statement can reach tables and operations the original feature never needed.

Impact: Sensitive records can be disclosed, altered, or deleted, and the database account used by the application can become a high-value compromise path. The same weakness can also undermine logging, auditing, and downstream trust in application data.

Related resources from NHI Mgmt Group

• How can teams decide whether to use SQL or natural-language-style tools for agents?
• How should security teams govern applications whose identity data only exists in SQL tables?
• How do SQL-backed apps affect non-human identity governance?
• Why do identity signals matter more than raw security telemetry?