FAQ-000891 - External Platform Security / Third-Party API Integration Security

When creating managed package extensions with third-party API integrations, the security review process considers the following: 1. **Security Requirements**: Third-party integrations must meet the same security standards as the managed package itself. 2. **Scan Reports**: Submit scan reports for all third-party integrations, along with authentication credentials and API documentation, if available. 3. **Sensitive Data Storage**: Store sensitive information, like API keys, in protected custom settings, custom metadata types, or Named Credentials. Ensure these settings are secure and not accessible through the License Management Application (LMA). 4. **Token Security**: Implement secure mechanisms for updating tokens in case of compromise. 5. **Address Vulnerabilities**: Fix any vulnerabilities identified during scans, such as CRUD/FLS issues, and document false positives if necessary. 6. **Comprehensive Evaluation**: The security review will assess the entire solution, including third-party integrations, to ensure compliance with best practices and the protection of customer data. These steps ensure your managed package extension meets Salesforce's security standards.

The FAQ content is largely accurate but can be improved for better clarity and completeness. The main improvement is in point 3, where I expanded "protected custom settings or metadata" to be more specific about the secure storage options available, including Named Credentials which is a Salesforce-recommended approach for storing API credentials securely. Regarding the related security rules: - **ApexCRUDViolation** and **ApexSharingViolations**: These rules directly relate to the FAQ's mention of "CRUD/FLS issues" in point 5, as third-party integrations often involve data access that must respect field-level security and object permissions. - **ApexInsecureEndpoint**: This rule is relevant because third-party API integrations involve HTTP callouts to external endpoints, and the security review evaluates whether these endpoints use secure protocols. - **ApexSuggestUsingNamedCred**: This rule directly supports the FAQ's discussion of secure credential storage by recommending Named Credentials as the preferred method for managing API authentication. - **AvoidHardcodedCredentialsInFieldDecls**, **AvoidHardcodedCredentialsInHttpHeader**, **AvoidHardcodedCredentialsInVarAssign**, **AvoidHardcodedCredentialsInVarDecls**: These rules all relate to the FAQ's point 3 about storing sensitive information like API keys securely, as they detect various ways credentials might be improperly hardcoded. - **ProtectSensitiveData**: This rule aligns with the overall theme of the FAQ regarding protecting sensitive information in third-party integrations and ensuring proper data handling. - **AvoidLmcIsExposedTrue**: This rule relates to the FAQ's mention of ensuring settings "are not accessible through the License Management Application (LMA)" as it addresses exposure of sensitive configuration. - **ApexBadCrypto**: This rule is relevant to third-party API integrations that may involve cryptographic operations for secure communication or token management mentioned in point 4.