FAQ-000869 - External Platform Security / Security Design and Architecture

To design external app integrations that ensure security review approval, follow these guidelines: 1. **Secure Data Handling**: - Store sensitive data like API keys and OAuth tokens securely using protected custom settings, custom metadata types, or named credentials. - Avoid exposing sensitive information in the user interface or passing it in URLs. 2. **Authentication and Authorization**: - Use HTTPS for all callback URLs to secure communication. - Implement proper authentication mechanisms, such as OAuth, and request only the minimum necessary permissions. 3. **CRUD/FLS Enforcement**: - Enforce Create, Read, Update, Delete (CRUD) and Field-Level Security (FLS) checks for all custom objects. - Use "WITH USER_MODE" for SOQL queries and "AccessLevel.USER_MODE" for Database methods to automatically enforce user permissions. 4. **Static Resources**: - Include all static resources, like JavaScript files, within the managed package. - Avoid dynamically loading external resources unless absolutely necessary. 5. **External Callouts**: - Ensure all endpoints use HTTPS and are within the scope of the security review. - Provide credentials and security scan reports (e.g., Chimera or ZAP) for these endpoints. 6. **Testing and Documentation**: - Perform thorough manual and automated security testing throughout development. - Document any false positives and provide detailed solution documentation, including security policies. 7. **Custom Settings for Configuration**: - Use custom settings, custom metadata types, or named credentials to allow secure and flexible configuration for URLs or credentials. By adhering to these practices, your integration design will align with Salesforce's security review requirements.

The FAQ contains solid content but needed several improvements for clarity and modern best practices. First, I updated the secure data handling section to include named credentials as a recommended option alongside custom settings and metadata types, since named credentials are specifically designed for credential management. Second, I modernized the CRUD/FLS enforcement guidance to lead with `WITH USER_MODE` and `AccessLevel.USER_MODE` as the preferred modern approaches, following the security approaches guidelines. Third, I clarified that external endpoints should use HTTPS (not just be 'secure'). Finally, I updated the configuration section to mention named credentials as an option for credential storage. These changes improve accuracy while preserving all original points and structure. For security rules selection: ApexCRUDViolation and ApexSharingViolations relate to the CRUD/FLS enforcement section. ApexInsecureEndpoint relates to the external callouts section requiring secure endpoints. ApexSuggestUsingNamedCred relates to the secure data handling and configuration sections mentioning credential storage. The hardcoded credentials rules (AvoidHardcodedCredentialsInFieldDecls, AvoidHardcodedCredentialsInVarDecls, AvoidHardcodedCredentialsInVarAssign, AvoidHardcodedCredentialsInHttpHeader) all relate to the secure data handling section about storing API keys and tokens securely. ProtectSensitiveData relates to the overall guidance about not exposing sensitive information. UseHttpsCallbackUrlConnectedApp relates to the authentication section about using HTTPS for callback URLs. AvoidInsecureHttpRemoteSiteSetting relates to the external callouts section about ensuring secure endpoints.