A raw query is SQL assembled directly as text, often with string interpolation or concatenation. It is flexible, but that flexibility creates risk because any untrusted value inserted into the string can become part of the executable statement rather than a safe parameter.
What a raw query is and how it works
A raw query is SQL assembled directly as text, often through concatenation or interpolation. That makes it simple to compose, but it also means the database will execute whatever text is produced, not just what the developer intended.
The key idea is that a raw query is not intrinsically unsafe, it becomes dangerous when untrusted input is allowed to shape the final statement. At that point, the query string itself is the attack surface.
Why raw queries are used
Developers often reach for raw queries when they need dynamic filtering, unusual joins, vendor-specific SQL features, or performance tuning that an abstraction layer does not expose cleanly. In those cases, raw SQL can be the most direct way to express the logic.
The trade-off is control versus safety. The more a query is built as free-form text, the more careful the surrounding code must be about quoting, encoding, and separating data from executable syntax.
How raw queries differ from parameterized queries
In a parameterized query, values are passed separately from the SQL text, so the database treats them as data. In a raw query, the application often builds the full statement first, which means a malicious value can alter the structure of the query if it is not properly controlled.
That distinction matters because SQL injection does not require a complex flaw, only a place where attacker-controlled text can become part of the executable statement. Secure parameter binding removes that ambiguity by preserving a hard boundary between code and data.
Where raw queries fit in secure development
Raw queries are sometimes justified, but they should be treated as a deliberate exception rather than a default pattern. The safer the surrounding data-access layer, the fewer places there are for interpolation mistakes, inconsistent escaping, or hidden injection paths to appear.
When raw SQL is unavoidable, it should be reviewed with the same care as other security-sensitive code because even a small string-building shortcut can change query semantics, expose data, or enable unintended write operations.
Risk and Threat Considerations
Raw queries materially increase exposure to SQL injection when untrusted values are concatenated into the statement. The same pattern can also create broader integrity and confidentiality risk, because an attacker who changes the query structure may read, modify, or delete data the application was never meant to expose.
Failure mechanism: User-controlled text is inserted into the SQL command itself, so the database interprets attacker input as executable syntax rather than as data.
Impact: The result can range from unauthorized record access to destructive database actions, depending on the privileges of the database account and the exact query path.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP API Security Top 10 addresses the attack and risk surface, while OWASP ASVS and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V8 — Authorization | Raw queries can bypass intended access checks through injected SQL structure. |
| V14 — Data Protection | Raw queries can expose or modify sensitive data when input becomes executable SQL. | |
| Recommendation — Validate query paths so injected SQL cannot alter authorization decisions. Use parameter binding to keep untrusted values out of executable SQL text. | ||
| NIST SP 800-53 Rev 5 | SI-10 — Information Input Validation | Raw query safety depends on validating and constraining externally supplied input before use. |
| Recommendation — Validate input before it is incorporated into SQL statements. | ||
| OWASP API Security Top 10 | API8 — Security Misconfiguration | Unsafe query construction is a common configuration and implementation weakness in data-access layers. |
| Recommendation — Harden data-access code to prevent unsafe query construction paths. | ||
Practitioner Guidance
Common misunderstanding: A raw query is not automatically a vulnerability, but it demands stronger discipline than ORM-generated or parameterized access. The important question is whether any part of the statement can be influenced by untrusted input without strict separation between code and data.
Practitioner takeaway: Use raw SQL only where its flexibility is genuinely needed, and treat every interpolation point as a security review item because the risk comes from composition, not from SQL syntax alone.
Related resources from NHI Mgmt Group
- What breaks when agents are allowed to query raw microservices and databases directly?
- How should security teams let coding agents query observability data without exposing raw traces to model context?
- Raw query escape hatch
- How should security teams govern AI agents that query sensitive data in Snowflake?
Deepen Your Knowledge
Free weekly newsletter
Subscribe to the NHI & AI Identity Journal
The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.
Bonus 33% off our NHI Course when you subscribe.
Reviewed and updated by the NHIMG editorial team on October 13, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org