FAQ-001591 - SQL Injection and Input Validation / Dynamic SOQL Query Construction

Current Status:VALID_RESPONSEErrorUnable to AnswerSuggests Case

Current FAQ

Question
What are the secure alternatives to dynamic SOQL when standard binding isn't possible for SObject or field names?
Answer
To securely handle dynamic SOQL when standard binding isn't possible for SObject or field names, you can follow these best practices: 1. **Validate SObject Names**: Use `Schema.getGlobalDescribe()` to get a map of all SObject names and ensure the user-supplied object name exists in the schema. 2. **Validate Field Names**: Retrieve the field map using `getDescribe()` on the SObject and validate the user-supplied field name against this map. 3. **Sanitize Inputs**: Avoid using raw user input in SOQL queries. Use methods like `String.escapeSingleQuotes()` for sanitizing simple string comparisons. 4. **Check Permissions**: Implement proper CRUD (Create, Read, Update, Delete) and FLS (Field-Level Security) checks to ensure the user has the necessary permissions for the specified object or field. 5. **Use `with SECURITY_ENFORCED`**: Include this clause in SOQL queries to enforce field- and object-level security automatically. 6. **Programmatic Query Construction**: Use `sObjectType` or `sObjectFields` to construct queries programmatically, avoiding raw strings. These steps help prevent SOQL injection and unauthorized data access when traditional bind variables cannot be used for object and field names.
Enhancing FAQ...

Enhancing FAQ with AI recommendations...

AI Recommended Enhancement

Related Security Rules (click to view)
ApexSOQLInjectionApexCRUDViolation
Question
What are the secure alternatives to dynamic SOQL when standard binding isn't possible for SObject or field names?
Recommended Answer Update
To securely handle dynamic SOQL when standard binding isn't possible for SObject or field names, you can follow these best practices: 1. **Validate SObject Names**: Use `Schema.getGlobalDescribe()` to get a map of all SObject names and ensure the user-supplied object name exists in the schema. 2. **Validate Field Names**: Retrieve the field map using `getDescribe()` on the SObject and validate the user-supplied field name against this map. 3. **Sanitize Inputs**: Avoid using raw user input in SOQL queries. Use methods like `String.escapeSingleQuotes()` for sanitizing simple string comparisons. 4. **Check Permissions**: Implement proper CRUD (Create, Read, Update, Delete) and FLS (Field-Level Security) checks to ensure the user has the necessary permissions for the specified object or field. 5. **Use `WITH USER_MODE`**: Include this clause in SOQL queries to automatically enforce field- and object-level security. 6. **Programmatic Query Construction**: Use `sObjectType` or `sObjectFields` to construct queries programmatically, avoiding raw strings. These steps help prevent SOQL injection and unauthorized data access when traditional bind variables cannot be used for object and field names.
Reasoning
The main change needed is updating the outdated `WITH SECURITY_ENFORCED` clause to the modern `WITH USER_MODE` clause. According to the security approaches guidelines, we should prioritize modern features over legacy approaches, and `WITH USER_MODE` is the current recommended approach for automatically enforcing permissions in SOQL queries while requiring less code. The `WITH SECURITY_ENFORCED` clause is the older approach that has been superseded. For the security rules selected: - ApexSOQLInjection: This rule directly relates to the core topic of this FAQ, which is about preventing SOQL injection when dynamic SOQL construction is necessary. The FAQ content specifically mentions "prevent SOQL injection" and discusses techniques like input validation and sanitization that are fundamental to SOQL injection prevention. - ApexCRUDViolation: This rule relates to the FAQ's discussion of "proper CRUD (Create, Read, Update, Delete) and FLS (Field-Level Security) checks" and the recommendation to "ensure the user has the necessary permissions for the specified object or field," which are core CRUD violation prevention practices.
Reasoning References
Recommended Related Articles