FAQ-000859 - External Platform Security / External Web Applications and SaaS

To implement security measures for web app integrations accessed through Salesforce, follow these guidelines: 1. **Authentication**: Use OAuth tokens for authentication instead of session IDs. If session IDs are necessary, obtain them through approved methods (e.g., Visualforce pages) and avoid unnecessary exposure. 2. **Access Control**: Enforce CRUD (Create, Read, Update, Delete) and FLS (Field-Level Security) checks for all data operations. Use `WITH USER_MODE` for SOQL queries and `AccessLevel.USER_MODE` for Database methods when possible, as these automatically enforce permissions. 3. **Secure Data Storage**: Store sensitive information like API keys or secrets securely using Named Credentials, protected custom metadata, or protected custom settings. Avoid exposing sensitive data in logs or debug statements. 4. **Security Testing**: Conduct thorough security testing, including manual and automated scans, to identify vulnerabilities. Document and address any false positives. 5. **Static Resources**: Avoid dynamically loading third-party JavaScript or CSS files. Instead, include these resources in the static resources folder of your package. 6. **Secure Endpoints**: Ensure all external endpoints use HTTPS and securely transfer credentials and data. Obtain permissions for security testing on third-party endpoints. 7. **Documentation**: Provide detailed documentation on security measures and configurations to help reviewers and users understand the integration's security posture. 8. **Compliance**: Follow Salesforce's security guidelines and submit required materials, such as security scan reports and false-positive documentation, during the AppExchange security review process. These steps will help protect customer data and ensure compliance with Salesforce security standards.

The FAQ content was mostly accurate but needed refinement in several areas to align with current security best practices. Key improvements made: 1. **Access Control Enhancement**: Added modern security enforcement approaches by mentioning `WITH USER_MODE` and `AccessLevel.USER_MODE` as preferred methods for enforcing permissions, while preserving the existing CRUD/FLS guidance. 2. **Secure Data Storage Improvement**: Enhanced the recommendation to specifically mention Named Credentials as the preferred method for storing API keys and secrets, while maintaining the existing protected metadata/settings options. 3. **Endpoint Security Clarification**: Made the HTTPS requirement explicit by changing "securely transfer" to "use HTTPS and securely transfer" for better clarity. These changes improve the FAQ's alignment with security scanner rules and modern best practices without removing any existing content or adding new points. **Security Rules Selection Reasoning**: - **AvoidApiSessionId**: Relates to point 1 about using OAuth tokens instead of session IDs - "Use OAuth tokens for authentication instead of session IDs" - **ApexCRUDViolation**: Directly relates to point 2 about enforcing CRUD checks - "Enforce CRUD (Create, Read, Update, Delete) and FLS checks" - **ApexSharingViolations**: Connects to point 2's access control requirements for data operations security - **ApexSuggestUsingNamedCred**: Aligns with point 3's guidance on secure storage - "Store sensitive information like API keys or secrets securely using Named Credentials" - **AvoidHardcodedCredentialsInFieldDecls/VarDecls/HttpHeader**: All relate to point 3's secure storage recommendations - "Store sensitive information like API keys or secrets securely" - **ApexInsecureEndpoint**: Matches point 6's endpoint security requirements - "Ensure all external endpoints use HTTPS and securely transfer credentials" - **LoadJavaScriptIncludeScript/LoadCSSLinkHref**: Both relate to point 5's static resource guidance - "Avoid dynamically loading third-party JavaScript or CSS files"