FAQ-001649 - Salesforce Platform Security Responsibility / Security Documentation and Reporting

Current Status:SUGGESTS_CASEErrorUnable to AnswerSuggests Case

← Back to List View Prompt Template

Current FAQ

Question
How should I handle security documentation and reporting for Salesforce domains and authentication URLs flagged in security reviews?
Answer
**For Salesforce-Owned Domains:** I couldn't find specific information about the security documentation needed for Salesforce-owned domains. I recommend opening a case with Salesforce support for further clarification. **For Salesforce Domains Flagged as External Endpoints:** To handle security scan requirements for Salesforce domains (like Einstein APIs) flagged as external endpoints: 1. Perform a Dynamic Application Security Test (DAST) scan using tools like ZAP, Burp Suite, HCL AppScan, or WebInspect 2. Include the DAST scan reports in your security review submission 3. Obtain any necessary permissions to perform security testing on external endpoints that you do not own 4. Follow the guidelines in Salesforce IP Addresses & Domains to Allow 5. Document any false positives and provide explanations for them in your submission **For Standard Salesforce Authentication URLs:** To document a standard Salesforce authentication URL flagged as a vulnerability: 1. **Describe the URL**: Clearly state that it is a standard Salesforce authentication URL and explain its purpose in your application 2. **Justify its use**: Provide a rationale for why the flagged URL is not a security risk, emphasizing that it is a secure, Salesforce-provided endpoint 3. **Provide evidence**: Reference Salesforce documentation or guidelines that confirm the URL's legitimacy and security 4. **Mention mitigation measures**: If applicable, describe additional security measures, like enforcing HTTPS or restricting access to authorized users **For Login URLs Flagged in Security Reviews:** To address security concerns about login URLs: 1. Review the information provided in the "Provide Environments" step of the security review wizard 2. Ensure that the authentication credentials are valid 3. Verify that the access URL for the web app or service is correct 4. Update the details as needed to resolve the flagged issues **Reporting as False Positives:** To report standard Salesforce login or authentication URLs as false positives: 1. Include a false-positive explanatory document in your submission 2. Clearly explain why the flagged URL does not pose a security risk 3. Support your claim by detailing that the URL is nonexploitable or required for valid functionality 4. Submit this document along with your security review materials through the AppExchange Partner Console Note: There is no fee for evaluating false-positive documentation. **For Standard Component Security Issues:** I couldn't find specific guidance on documenting Salesforce standard component security issues. I recommend reaching out to Salesforce support or opening a case for detailed assistance.

Enhancing FAQ with AI recommendations...

AI Recommended Enhancement

Related Security Rules (click to view)
ApexInsecureEndpointApexSuggestUsingNamedCredAvoidDisableProtocolSecurityRemoteSiteSettingAvoidInsecureHttpRemoteSiteSetting
Question
How should I handle security documentation and reporting for Salesforce domains and authentication URLs flagged in security reviews?
Recommended Answer Update
**For Salesforce-Owned Domains:** I couldn't find specific information about the security documentation needed for Salesforce-owned domains. I recommend opening a case with Salesforce support for further clarification. **For Salesforce Domains Flagged as External Endpoints:** To handle security scan requirements for Salesforce domains (like Einstein APIs) flagged as external endpoints: 1. Perform a Dynamic Application Security Test (DAST) scan using tools like ZAP, Burp Suite, HCL AppScan, or WebInspect 2. Include the DAST scan reports in your security review submission 3. Obtain any necessary permissions to perform security testing on external endpoints that you don't own 4. Follow the guidelines in Salesforce IP Addresses & Domains to Allow 5. Document any false positives and provide explanations for them in your submission **For Standard Salesforce Authentication URLs:** To document a standard Salesforce authentication URL flagged as a vulnerability: 1. **Describe the URL**: Clearly state that it's a standard Salesforce authentication URL and explain its purpose in your application 2. **Justify its use**: Provide a rationale for why the flagged URL isn't a security risk, emphasizing that it's a secure, Salesforce-provided endpoint 3. **Provide evidence**: Reference Salesforce documentation or guidelines that confirm the URL's legitimacy and security 4. **Mention mitigation measures**: If applicable, describe additional security measures, like enforcing HTTPS or restricting access to authorized users **For Login URLs Flagged in Security Reviews:** To address security concerns about login URLs: 1. Review the information provided in the "Provide Environments" step of the security review wizard 2. Ensure that the authentication credentials are valid 3. Verify that the access URL for the web app or service is correct 4. Update the details as needed to resolve the flagged issues **Reporting as False Positives:** To report standard Salesforce login or authentication URLs as false positives: 1. Include a false-positive explanatory document in your submission 2. Clearly explain why the flagged URL doesn't pose a security risk 3. Support your claim by detailing that the URL is nonexploitable or required for valid functionality 4. Submit this document along with your security review materials through the AppExchange Partner Console Note: There's no fee for evaluating false-positive documentation. **For Standard Component Security Issues:** I couldn't find specific guidance on documenting Salesforce standard component security issues. I recommend reaching out to Salesforce support or opening a case for detailed assistance.
Reasoning
The content was reviewed for consistency with security best practices and conversational tone guidelines. Minor improvements were made to enhance readability and maintain a more natural, conversational tone: 1. Changed contractions: "is not" to "isn't", "does not" to "doesn't", "do not" to "don't", "There is" to "There's" 2. Simplified "it is" to "it's" for better flow These changes align with the brand guidelines to use conversational language and contractions while maintaining all original technical content and structure. Regarding security rules: - **ApexInsecureEndpoint**: This rule relates to the FAQ's discussion of external endpoints and authentication URLs that may be flagged in security scans. The FAQ addresses how to handle Salesforce domains flagged as external endpoints and document authentication URLs properly. - **ApexSuggestUsingNamedCred**: This rule connects to the FAQ's guidance on documenting external endpoints and authentication, as named credentials are a secure way to handle external service authentication that reviewers look for. - **AvoidDisableProtocolSecurityRemoteSiteSetting**: This rule relates to the FAQ's emphasis on enforcing HTTPS and maintaining secure endpoints, which is mentioned in the mitigation measures section. - **AvoidInsecureHttpRemoteSiteSetting**: This rule directly connects to the FAQ's discussion of secure endpoints and the requirement to use HTTPS for authentication URLs and external endpoints.
Reasoning References