FAQ-000917 - External Service Security Testing / Scan Configuration and Setup

Current Status:VALID_RESPONSEErrorUnable to AnswerSuggests Case

← Back to List View Prompt Template

Current FAQ

Question
How should I provide the security review team access to scan my external web application and configure endpoints properly?
Answer
To provide the security review team access to scan your external web application for a managed package: 1. **Include URLs and Login Credentials**: Provide the URLs and login credentials for any external components requiring authentication as part of your security review submission. 2. **Ensure Accessibility**: Make sure all environments, packages, and external components used by your solution are accessible to the review team. 3. **Submit DAST Scan Reports**: Include Dynamic Application Security Test (DAST) scan reports in your submission. 4. **Provide Documentation**: Add any necessary documentation, such as explanations for false positives, if applicable. 5. **Scope Verification**: Ensure the endpoint is within the scope of the security review. 6. **Obtain Permissions**: If the endpoint is not owned by you, get permission from the owner to perform the scan. 7. **Use a DAST Scanner**: Utilize a Dynamic Application Security Test (DAST) scanner like ZAP or Burp Suite to analyze the endpoint. 8. **Set Up Proxy**: Configure the scanner as a proxy to capture and analyze requests and responses. 9. **Ensure Compliance**: Verify that the endpoint complies with security requirements, such as: - Using TLS v1.2 or above - Marking session IDs as secure 10. **Token Placement**: If the endpoint requires a token for scanning, ensure it is placed in the web application root. 11. **Address Vulnerabilities**: Document and resolve any vulnerabilities identified during the scan. This ensures the review team can securely test the external components and verify compliance with security standards.

Enhancing FAQ with AI recommendations...

AI Recommended Enhancement

Related Security Rules (click to view)
ApexInsecureEndpointApexSuggestUsingNamedCredAvoidHardcodedCredentialsInHttpHeaderAvoidHardcodedCredentialsInFieldDeclsAvoidHardcodedCredentialsInVarDeclsAvoidInsecureHttpRemoteSiteSettingAvoidDisableProtocolSecurityRemoteSiteSettingUseHttpsCallbackUrlConnectedApp
Question
How should I provide the security review team access to scan my external web application and configure endpoints properly?
Recommended Answer Update
To provide the security review team access to scan your external web application for a managed package: 1. **Include URLs and Login Credentials**: Provide the URLs and login credentials for any external components requiring authentication as part of your security review submission. 2. **Ensure Accessibility**: Make sure all environments, packages, and external components used by your solution are accessible to the review team. 3. **Submit DAST Scan Reports**: Include Dynamic Application Security Test (DAST) scan reports in your submission. 4. **Provide Documentation**: Add any necessary documentation, such as explanations for false positives, if applicable. 5. **Verify Scope**: Ensure the endpoint is within the scope of the security review. 6. **Obtain Permissions**: If the endpoint isn't owned by you, get permission from the owner to perform the scan. 7. **Use a DAST Scanner**: Use a Dynamic Application Security Test (DAST) scanner like ZAP or Burp Suite to analyze the endpoint. 8. **Set Up Proxy**: Configure the scanner as a proxy to capture and analyze requests and responses. 9. **Ensure Compliance**: Verify that the endpoint complies with security requirements, such as: - Using TLS v1.2 or above - Marking session IDs as secure 10. **Token Placement**: If the endpoint requires a token for scanning, ensure it's placed in the web application root. 11. **Address Vulnerabilities**: Document and resolve any vulnerabilities identified during the scan. This ensures the review team can securely test the external components and verify compliance with security standards.
Reasoning
The FAQ content was generally well-structured but had some minor wording improvements that could make it clearer and more conversational. I made these refinements: Changed 'Scope Verification' to 'Verify Scope' for better action-oriented language, changed 'If the endpoint is not owned by you' to 'If the endpoint isn't owned by you' for a more conversational tone using contractions, and changed 'Utilize' to 'Use' for simpler, more direct language. These changes align with the brand guidelines to be more conversational and direct while maintaining all the original technical content and structure. Regarding security rules: ApexInsecureEndpoint relates to the FAQ's emphasis on HTTPS/TLS requirements and secure endpoint configuration. ApexSuggestUsingNamedCred connects to the credential management aspects mentioned in points 1 and 6 about providing login credentials and obtaining permissions. The hardcoded credentials rules (AvoidHardcodedCredentialsInHttpHeader, AvoidHardcodedCredentialsInFieldDecls, AvoidHardcodedCredentialsInVarDecls) relate to the credential handling aspects discussed in the authentication and token placement sections. AvoidInsecureHttpRemoteSiteSetting and AvoidDisableProtocolSecurityRemoteSiteSetting relate to the TLS v1.2 requirement and secure communication standards mentioned in point 9. UseHttpsCallbackUrlConnectedApp connects to the overall HTTPS/secure communication theme that runs throughout the endpoint security requirements.
Reasoning References