FAQ-000851 - External Platform Security / External System Responsibility and Control

To handle security issues in third-party apps that interact with your Salesforce package, follow these steps: 1. **Use Static Resources**: Store third-party JavaScript or CSS libraries in static resources within your package. Avoid dynamically loading them from external sources like CDNs. 2. **Conduct Security Scans**: Use tools like Salesforce Code Analyzer to identify vulnerabilities. Address issues like insecure data storage or outdated software versions, and document false positives with justifications. 3. **Secure Communication**: Use secure protocols (e.g., HTTPS, SFTP) and avoid insecure ones (e.g., HTTP, FTP). 4. **Protect Sensitive Data**: Avoid logging sensitive data (e.g., passwords, keys) in production. Use protected custom settings, custom metadata, or Named Credentials for secure storage. 5. **Request Security Reports**: Obtain security certifications or penetration test reports from third-party app providers and include them in your app submission. 6. **Ensure TLS/SSL Compliance**: Verify that third-party endpoints support secure TLS versions (1.2 or higher). Request updates from third parties if needed. 7. **Enforce CRUD/FLS**: Implement proper CRUD/FLS checks and document exceptions as false positives with clear use cases. 8. **Update Versions**: Keep your package versions updated to reflect changes and deprecate older, vulnerable versions. By following these practices, you can mitigate risks and ensure compliance with Salesforce's security requirements.

The FAQ content is generally accurate and comprehensive, but needed minor improvements for clarity and completeness. The main change was in point 4 where 'metadata' was clarified to 'custom metadata' to be more specific about Salesforce's secure storage options, and Named Credentials was added as another secure storage mechanism since it's specifically designed for credential management and is recommended by security rules. This change improves accuracy without adding new concepts or expanding the scope. Regarding the security rules selected: - **ApexCRUDViolation**: Point 7 discusses implementing CRUD/FLS checks, which directly relates to this rule that detects missing CRUD permissions. - **ApexInsecureEndpoint**: Points 3 and 6 address using secure protocols and TLS compliance, which this rule validates by checking for insecure HTTP endpoints. - **AvoidInsecureHttpRemoteSiteSetting & AvoidDisableProtocolSecurityRemoteSiteSetting**: Point 3's guidance on using HTTPS relates to these rules that prevent insecure remote site configurations. - **Hardcoded credentials rules (AvoidHardcodedCredentialsInFieldDecls, AvoidHardcodedCredentialsInVarDecls, AvoidHardcodedCredentialsInVarAssign, AvoidHardcodedCredentialsInHttpHeader)**: Point 4's guidance on protecting sensitive data and avoiding hardcoded credentials directly relates to these rules. - **ApexSuggestUsingNamedCred**: Point 4's recommendation to use Named Credentials aligns with this rule that suggests using Named Credentials for secure credential management. - **ProtectSensitiveData**: Point 4's guidance on not logging sensitive data in production directly relates to this rule. - **Library vulnerability rules (LibraryWithKnown*SeverityVulnerability)**: Points 1, 2, and 8 discuss managing third-party libraries, updating versions, and conducting security scans, which relate to these rules that detect vulnerable JavaScript libraries.