FAQ-001601 - SQL Injection and Input Validation / False Positive Identification and Documentation

Current Status:VALID_RESPONSEErrorUnable to AnswerSuggests Case

Current FAQ

Question
What documentation is needed to prove SOQL injection vulnerabilities are incorrect?
Answer
To prove that SOQL injection vulnerabilities are incorrect, your documentation should include: 1. **Bind Variables**: Evidence of using bind variables in the SOQL queries to prevent user input from breaking out of its quoted context. 2. **Input Validation/Sanitization**: Details of input validation or sanitization methods, like `String.escapeSingleQuotes()`, applied to user-supplied data. 3. **Permission Enforcement**: Verification that user permissions are enforced before executing queries, such as using `WITH SECURITY_ENFORCED` or checking object and field-level permissions. 4. **Query Context**: A clear explanation showing that the query does not allow user-controlled portions beyond object names, field names, or WHERE clause inputs. 5. **Security Context**: Evidence that the query does not execute in a way that could elevate privileges or expose sensitive data. 6. **Code Review Evidence**: Include results from static code analysis tools (e.g., Salesforce Source Code Analyzer) showing no SOQL injection vulnerabilities. Address any false positives with detailed explanations. 7. **Security Review Compliance**: Attach prior security review reports or approvals confirming no vulnerabilities. 8. **Testing Evidence**: Provide results from penetration tests or automated security scans validating the absence of SOQL injection risks. Include relevant logs, code snippets, test results, or screenshots to validate these points and provide clear, detailed documentation to support your claims.
Enhancing FAQ...

Enhancing FAQ with AI recommendations...

AI Recommended Enhancement

Related Security Rules (click to view)
ApexSOQLInjection
Question
What documentation is needed to prove SOQL injection vulnerabilities are incorrect?
Recommended Answer Update
To prove that SOQL injection vulnerabilities are incorrect, your documentation should include: 1. **Bind Variables**: Evidence of using bind variables in the SOQL queries to prevent user input from breaking out of its quoted context. 2. **Input Validation/Sanitization**: Details of input validation or sanitization methods, like `String.escapeSingleQuotes()`, applied to user-supplied data. 3. **Permission Enforcement**: Verification that user permissions are enforced before executing queries, such as using `WITH USER_MODE` or checking object and field-level permissions. 4. **Query Context**: A clear explanation showing that the query does not allow user-controlled portions beyond object names, field names, or WHERE clause inputs. 5. **Security Context**: Evidence that the query does not execute in a way that could elevate privileges or expose sensitive data. 6. **Code Review Evidence**: Include results from static code analysis tools (e.g., Salesforce Code Analyzer) showing no SOQL injection vulnerabilities. Address any false positives with detailed explanations. 7. **Security Review Compliance**: Attach prior security review reports or approvals confirming no vulnerabilities. 8. **Testing Evidence**: Provide results from penetration tests or automated security scans validating the absence of SOQL injection risks. Include relevant logs, code snippets, test results, or screenshots to validate these points and provide clear, detailed documentation to support your claims.
Reasoning
The main change needed was updating 'WITH SECURITY_ENFORCED' to 'WITH USER_MODE' in point 3, as per the security approaches guidelines that prioritize modern features. WITH USER_MODE is the current recommended approach for enforcing permissions in SOQL queries. Additionally, updated 'Salesforce Source Code Analyzer' to 'Salesforce Code Analyzer' to reflect the current tool name. The ApexSOQLInjection rule is directly relevant because this FAQ specifically addresses how to document and prove that SOQL injection vulnerabilities are false positives. The rule detects potential SOQL injection vulnerabilities, and this FAQ provides guidance on the exact documentation needed to demonstrate that flagged instances are not actual vulnerabilities.
Reasoning References
Recommended Related Articles