A query injection flaw caused by placing user controlled input directly into a Salesforce Object Query Language statement. Attackers can alter the query logic to expose or manipulate data. The standard mitigation is bind variables, strict input validation, and typecasting before values are used in dynamic query construction.
What SOQL injection is
SOQL injection is a query-injection weakness in Salesforce applications. It occurs when untrusted input is concatenated into a Salesforce Object Query Language statement, allowing an attacker to change the query’s meaning and access data they should not see.
The flaw is closely related to other injection classes, but the target is a Salesforce query context rather than SQL itself. The security problem is not the language alone, it is unsafe dynamic query construction that lets attacker-controlled text become executable query logic.
How SOQL injection works
SOQL becomes dangerous when developers build filters, predicates, or field constraints from raw input without proper binding or validation. An attacker can then alter operators, boolean logic, or query structure so the application returns broader result sets or reveals records outside the intended scope.
In practice, this often shows up in search, filter, sort, and record lookup features. Even small input fragments can be enough to change query behaviour if the application treats the input as part of the statement instead of as data.
Why SOQL injection matters
The primary impact is unauthorized data exposure, but the blast radius can extend to data manipulation when the application uses the query result to drive later actions. A successful attack can also undermine tenant isolation, access checks, and business logic that assumes the query will only return authorized records.
Because SOQL is frequently used in business applications that handle sensitive customer, account, and operational data, injection defects can turn a normal lookup into a confidentiality failure. OWASP Top 10 remains the standard reference point for understanding why injection flaws are still a core application security issue.
Prevention and secure construction
The safest pattern is to separate code from data. Use bind variables wherever the platform and language support them, validate and typecast input before it reaches a dynamic query, and avoid string concatenation for query fragments unless the value is fully controlled and constrained.
When dynamic query construction is unavoidable, keep the allowed input space narrow and explicit. Query shape, field names, operators, and sorting logic should come from trusted application logic, not from user input, because those elements determine how the query executes.
For teams that want a broader control lens, input handling and query construction fit naturally into secure coding and verification practices covered by OWASP Top 10 guidance and OWASP API Security Top 10 when the vulnerable SOQL path is exposed through an API.
Risk and Threat Considerations
SOQL injection is risky because it turns ordinary application input into a data-access control bypass. The attacker does not need special platform access if they can influence the query construction path, which makes even low-privilege input fields a potential exposure point.
Failure mechanism: Unsafely concatenated query text lets an attacker modify predicates, widen result sets, or alter record selection logic. The issue is especially damaging when the query is used as the first gate before authorization or business-rule enforcement.
Impact: The most common outcome is unauthorized disclosure of Salesforce data, but downstream business effects can include record tampering, workflow abuse, and trust loss in reports or downstream automations that consume the tainted query results.
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 sets the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| OWASP ASVS | V2 — Validation and Business Logic | SOQL injection arises from unsafe input handling in query construction. |
| V15 — Secure Coding and Architecture | Dynamic query building is a secure-design issue that must separate code from data. | |
| V16 — Security Logging and Error Handling | Query injection attempts should be visible through logging and safe error handling. | |
| Recommendation — Validate and constrain all user input before it can alter dynamic SOQL logic. Design SOQL access paths so trusted code defines query structure and input only supplies data. Log suspicious query failures and avoid error messages that reveal query structure. | ||
| OWASP API Security Top 10 | API1 — Broken Object Level Authorization | Injected SOQL can bypass object and record access assumptions in API-backed lookups. |
| API5 — Broken Function Level Authorization | Attackers may reach functions that expose broader query behaviour than intended. | |
| Recommendation — Enforce object and record authorization independently of query parameters. Restrict query-building and search functions to authorized roles only. | ||
Practitioner Guidance
What to watch for: Treat any code path that assembles SOQL from user input as a review priority, especially search screens, flexible filters, and reporting features. If a developer must support dynamic behaviour, the safer design is to constrain the query structure in code and pass only validated values into it.
Practitioner takeaway: If user input can influence the text of the query, assume the query is attacker-facing until binding and validation prove otherwise.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on September 30, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
