What security requirements apply to off-platform components of my managed package?
Answer
Off-platform components of your managed package must meet Salesforce's security requirements to ensure secure data handling and integration. Here are the key requirements:
1. **Secure Communication**: Use secure protocols like HTTPS or SFTP for all communication. Avoid unsecured protocols like HTTP or FTP.
2. **Security Testing**: Perform Dynamic Application Security Testing (DAST) on external endpoints and provide the results during the security review. Document false positives and address identified vulnerabilities.
3. **Authentication and Data Handling**: Securely handle Salesforce credentials and data, including proper encryption and secure storage of sensitive information.
4. **Documentation and Access**: Provide detailed documentation of the external components, including their functionality and security measures. Grant access to test environments and external components for the security review.
5. **Code and Dependency Management**: Avoid dynamically loading third-party JavaScript or other code from external sources. Include such resources as static assets within the managed package for better version control and security.
6. **Compliance with Security Standards**: Follow industry security standards and Salesforce's secure coding guidelines to prevent vulnerabilities like injection attacks or improper data exposure.
These measures ensure that your off-platform components meet enterprise security standards and align with Salesforce's security review requirements.
What security requirements apply to off-platform components of my managed package?
Recommended Answer Update
Off-platform components of your managed package must meet Salesforce's security requirements to ensure secure data handling and integration. Here are the key requirements:
1. **Secure Communication**: Use secure protocols like HTTPS or SFTP for all communication. Avoid unsecured protocols like HTTP or FTP.
2. **Security Testing**: Perform Dynamic Application Security Testing (DAST) on external endpoints and provide the results during the security review. Document false positives and address identified vulnerabilities.
3. **Authentication and Data Handling**: Securely handle Salesforce credentials and data. Use Named Credentials for external service authentication rather than hardcoding credentials. Implement proper encryption and secure storage of sensitive information.
4. **Documentation and Access**: Provide detailed documentation of the external components, including their functionality and security measures. Grant access to test environments and external components for the security review.
5. **Code and Dependency Management**: Include third-party JavaScript and other resources as static assets within the managed package rather than loading them dynamically from external sources. This provides better version control and security.
6. **Compliance with Security Standards**: Follow industry security standards and Salesforce's secure coding guidelines to prevent vulnerabilities like injection attacks or improper data exposure.
These measures ensure that your off-platform components meet enterprise security standards and align with Salesforce's security review requirements.
Reasoning
The FAQ content is largely accurate, but I made several refinements to align with security best practices and improve clarity:
1. **Enhanced Authentication Guidance**: Added specific mention of Named Credentials as the preferred method for external service authentication, which aligns with modern Salesforce security practices.
2. **Improved Dynamic Loading Language**: Refined point 5 to be more direct about including resources as static assets rather than "avoiding" dynamic loading, making the guidance more actionable.
3. **Maintained Structure**: Preserved all six key points and the overall structure while improving clarity and flow.
Regarding the selected security rules:
- **ApexInsecureEndpoint & AvoidInsecureHttpRemoteSiteSetting**: Directly relate to point 1 about secure communication protocols (HTTPS vs HTTP)
- **ApexSuggestUsingNamedCred**: Supports the enhanced guidance in point 3 about proper authentication methods
- **ApexBadCrypto**: Relates to point 3's emphasis on proper encryption for sensitive information
- **AvoidHardcodedCredentials rules (FieldDecls, VarDecls, HttpHeader)**: All relate to point 3's requirement for secure credential handling
- **AvoidDisableProtocolSecurityRemoteSiteSetting**: Supports point 1's secure communication requirements
- **LoadJavaScript and AvoidCreateElementScriptLinkTag rules**: Directly relate to point 5's guidance about including resources as static assets rather than loading dynamically