FAQ-001648 - Salesforce Platform Security Responsibility / SOQL Injection and API Endpoints

**Verifying API Endpoint Classification:** To verify if an API endpoint is considered internal or external to Salesforce: 1. **Evaluate the Endpoint's Role and Data Flow**: - Internal endpoints are hosted within Salesforce and operate entirely within its ecosystem - External endpoints involve systems or services outside Salesforce, typically for data transfer or authentication processes 2. **Determine the Endpoint's Purpose**: Check if the endpoint is used for authenticating users, transferring Salesforce data to/from an external system, or interacting with third-party services 3. **Classification**: If the endpoint involves external systems, it's classified as external and requires security testing, including obtaining permissions for testing from the third-party owner if applicable **Addressing SOQL Injection Findings:** To address SOQL injection findings related to Salesforce endpoints: 1. **Use Bind Variables and Input Sanitization**: - Always use bind variables in SOQL queries to securely pass user input and prevent injection risks - If bind variables aren't feasible, use methods like `String.escapeSingleQuotes()` for simple string comparisons 2. **Enforce Security with Modern Features**: - Use `WITH USER_MODE` in SOQL queries to automatically enforce CRUD and FLS permissions - For Database methods, use `AccessLevel.USER_MODE` to enforce user permissions - These modern approaches require less code and automatically handle permission validation - You can also perform explicit CRUD/FLS checks on objects and fields using methods like `isAccessible()`, `isCreateable()`, `isUpdateable()`, and `isDeletable()` if needed 3. **Limit User-Supplied Inputs**: - Avoid allowing users to supply portions of SOQL queries other than object names, field names, and WHERE clause inputs - Validate user input against a whitelist of acceptable values using `Schema.getGlobalDescribe()` 4. **Avoid Dynamic SOQL**: - Minimize the use of dynamic SOQL queries - If dynamic queries are necessary, ensure all input is properly sanitized and validated **Documenting Secure SOQL Patterns:** To document that certain SOQL patterns are platform-controlled and secure: 1. **Explain Secure Practices**: Highlight the use of bind variables and user permission validation 2. **Provide Examples**: Include examples of using `Schema.DescribeSObjectResult` to check object and field accessibility 3. **Reference Documentation**: Cite resources like the ISVforce Guide for secure coding practices 4. **Specify Platform Features**: Document the use of platform features like `with sharing` and modern permission enforcement **Testing and Documentation:** - Use both manual and automated security scanning tools to test your solution - Include all external endpoints in the testing scope - Document false positives with justifications in the Functional Package (FP) document - Follow Salesforce's secure coding guidelines for additional best practices - Category: Salesforce Platform Security Responsibility - Subcategory: SOQL Injection and API Endpoints

Updated the answer to follow the security approaches guidelines by prioritizing modern features like WITH USER_MODE and AccessLevel.USER_MODE while maintaining that traditional approaches remain valid. Made language more conversational by using contractions like 'isn't' and 'it's'. Selected security rules based on direct relevance to FAQ content: ApexSOQLInjection relates to the SOQL injection prevention techniques discussed (bind variables, input sanitization, avoiding dynamic SOQL). ApexCRUDViolation relates to the CRUD/FLS permission checking methods mentioned (isAccessible, isCreateable, etc.). ApexSharingViolations relates to the 'with sharing' platform feature referenced in the documentation section. ApexInsecureEndpoint relates to the API endpoint classification and security testing requirements discussed in the first section.