FAQ-000804 - External Content and Iframe Security / Third-Party Service Vulnerabilities

Current Status:VALID_RESPONSEErrorUnable to AnswerSuggests Case

Current FAQ

Question
How should developers handle security vulnerabilities and issues in third-party services?
Answer
When dealing with security vulnerabilities and issues in third-party services during the AppExchange Security Review: **Documentation and Evidence:** - Document the issues thoroughly and provide evidence that the vulnerability is external to your application - Provide updated Dynamic Application Security Test (DAST) scan reports - Include documentation of your responses to any false positives - Provide detailed solution user documentation and your company's information security policies - Include any security certifications or reports from the third-party service that demonstrate their compliance with security standards **Third-Party Communication:** - Contact the third-party service to report the issue and request a resolution - If the third party cannot resolve the issue promptly, include their response, certifications, or security reports in your submission - Provide as many details as possible, such as the target URL, class name, and location when presenting third-party responses **False Positive Documentation:** - If the vulnerability does not impact your application's functionality or security, document it as a false positive - Include this explanation in your submission with supporting evidence - Document the findings thoroughly and include them in the false positives (FP) documentation - Submit this documentation as part of your security review submission in the AppExchange Partner Console **Alternative Documentation for Scanning Restrictions:** - For integrations with major platforms that do not permit external scanning, provide alternative documentation: - Submit API documentation, authentication credentials, and available security certifications or compliance reports from the platform - Ensure sensitive data, such as API keys, is securely stored (e.g., in protected custom settings) - Follow best practices for data protection - Document any limitations or constraints regarding external scanning **Mitigation Strategies:** - Ensure all external components, such as web applications or services, are securely transferring Salesforce credentials and data - Avoid reliance on vulnerable components wherever possible - Ensure your package does not depend on or reference the vulnerable components - Include a detailed explanation about why the issue is beyond your control and how it does not impact your package's security This approach demonstrates due diligence and helps mitigate the impact of third-party vulnerabilities on your security review.
Enhancing FAQ...

Enhancing FAQ with AI recommendations...

AI Recommended Enhancement

Related Security Rules (click to view)
ApexInsecureEndpointAvoidInsecureHttpRemoteSiteSettingAvoidDisableProtocolSecurityRemoteSiteSettingApexSuggestUsingNamedCredProtectSensitiveData
Question
How should developers handle security vulnerabilities and issues in third-party services?
Recommended Answer Update
When dealing with security vulnerabilities and issues in third-party services during the AppExchange Security Review: **Documentation and Evidence:** - Document the issues thoroughly and provide evidence that the vulnerability is external to your application - Provide updated Dynamic Application Security Test (DAST) scan reports - Include documentation of your responses to any false positives - Provide detailed solution user documentation and your company's information security policies - Include any security certifications or reports from the third-party service that demonstrate their compliance with security standards **Third-Party Communication:** - Contact the third-party service to report the issue and request a resolution - If the third party can't resolve the issue promptly, include their response, certifications, or security reports in your submission - Provide as many details as possible, such as the target URL, class name, and location when presenting third-party responses **False Positive Documentation:** - If the vulnerability doesn't impact your application's functionality or security, document it as a false positive - Include this explanation in your submission with supporting evidence - Document the findings thoroughly and include them in the false positives (FP) documentation - Submit this documentation as part of your security review submission in the AppExchange Partner Console **Alternative Documentation for Scanning Restrictions:** - For integrations with major platforms that don't permit external scanning, provide alternative documentation: - Submit API documentation, authentication credentials, and available security certifications or compliance reports from the platform - Ensure sensitive data, such as API keys, is securely stored (e.g., in protected custom settings) - Follow best practices for data protection - Document any limitations or constraints regarding external scanning **Mitigation Strategies:** - Ensure all external components, such as web applications or services, are securely transferring Salesforce credentials and data - Avoid reliance on vulnerable components wherever possible - Ensure your package doesn't depend on or reference the vulnerable components - Include a detailed explanation about why the issue is beyond your control and how it doesn't impact your package's security This approach demonstrates due diligence and helps mitigate the impact of third-party vulnerabilities on your security review.
Reasoning
The content is comprehensive and accurate, but needed minor conversational tone improvements to align with the brand guidelines. I replaced several overly formal phrases: 'cannot resolve' became 'can't resolve', 'do not permit' became 'don't permit', 'does not impact' became 'doesn't impact', and 'does not depend on' became 'doesn't depend on'. These changes make the content more conversational and accessible while maintaining all technical accuracy and detail. Regarding security rules selected: - **ApexInsecureEndpoint**: This rule is directly relevant to the FAQ's discussion about ensuring secure transfer of credentials and data to third-party services. The FAQ mentions "Ensure all external components, such as web applications or services, are securely transferring Salesforce credentials and data" which directly relates to endpoint security. - **AvoidInsecureHttpRemoteSiteSetting**: The FAQ discusses integrations with third-party services and the need for secure data transfer. This rule applies when configuring remote site settings for these integrations to ensure they use secure protocols. - **AvoidDisableProtocolSecurityRemoteSiteSetting**: Related to the FAQ's emphasis on following "best practices for data protection" when integrating with third-party services, this rule ensures protocol security isn't disabled. - **ApexSuggestUsingNamedCred**: The FAQ specifically mentions storing "sensitive data, such as API keys, is securely stored (e.g., in protected custom settings)" and discusses authentication credentials for third-party integrations, making this rule highly relevant. - **ProtectSensitiveData**: This rule directly applies to the FAQ's discussion about handling "Salesforce credentials and data" securely when working with third-party services and storing sensitive information like API keys.
Reasoning References