FAQ-000953 - External Service Security Testing / Third-Party API and Service Scanning

Current Status:VALID_RESPONSEErrorUnable to AnswerSuggests Case

Current FAQ

Question
How should third-party API security be handled when scans aren't available?
Answer
When scans aren't available for third-party APIs during the AppExchange Security Review, you should submit the authentication credentials and any available API documentation for the third-party integration. Additionally, ensure that sensitive information, like API keys, is securely stored (e.g., in protected custom settings). If the integration involves sensitive data, such as payment details, you must adhere to compliance standards like PCI Compliance. For external SaaS integrations in the AppExchange Security Review, you should test the full scope of your solution, including all external endpoints that operate independently of the Salesforce platform. Use both manual testing and automated security scanner tools to identify vulnerabilities. Document any false-positive security violations and ensure all code complies with Salesforce security guidelines. Additionally, provide URLs and login credentials for external components requiring authentication as part of your submission.
Enhancing FAQ...

Enhancing FAQ with AI recommendations...

AI Recommended Enhancement

Related Security Rules (click to view)
ApexSuggestUsingNamedCredApexInsecureEndpointAvoidHardcodedCredentialsInFieldDeclsAvoidHardcodedCredentialsInVarAssignAvoidHardcodedCredentialsInVarDeclsAvoidHardcodedCredentialsInHttpHeaderAvoidInsecureHttpRemoteSiteSettingAvoidDisableProtocolSecurityRemoteSiteSettingProtectSensitiveData
Question
How should third-party API security be handled when scans aren't available?
Recommended Answer Update
When scans aren't available for third-party APIs during the AppExchange Security Review, you should submit the authentication credentials and any available API documentation for the third-party integration. Additionally, ensure that sensitive information, like API keys, is securely stored using Named Credentials or in Protected Custom Settings. If the integration involves sensitive data, such as payment details, you must adhere to compliance standards like PCI Compliance. For external SaaS integrations in the AppExchange Security Review, you should test the full scope of your solution, including all external endpoints that operate independently of the Salesforce platform. Use both manual testing and automated security scanner tools to identify vulnerabilities. Document any false-positive security violations and ensure all code complies with Salesforce security guidelines. Additionally, provide URLs and login credentials for external components requiring authentication as part of your submission.
Reasoning
The answer needed one key clarification to better align with security best practices. The original text mentioned 'protected custom settings' for storing API keys, but the preferred approach according to Salesforce security guidelines is Named Credentials, followed by Protected Custom Settings as an alternative. The change emphasizes Named Credentials first, then mentions Protected Custom Settings as an option. All other content remains unchanged as it accurately describes the security review requirements. Security rules selected: - ApexSuggestUsingNamedCred: The FAQ discusses storing authentication credentials for third-party APIs, and this rule specifically recommends using Named Credentials instead of hardcoded credentials - ApexInsecureEndpoint: The FAQ mentions external endpoints and third-party API integrations, which this rule helps identify when insecure HTTP endpoints are used - AvoidHardcodedCredentialsInFieldDecls, AvoidHardcodedCredentialsInVarAssign, AvoidHardcodedCredentialsInVarDecls, AvoidHardcodedCredentialsInHttpHeader: These rules directly relate to the FAQ's guidance about securely storing API keys and authentication credentials - AvoidInsecureHttpRemoteSiteSetting, AvoidDisableProtocolSecurityRemoteSiteSetting: These rules apply to the external API integrations discussed in the FAQ - ProtectSensitiveData: The FAQ specifically mentions sensitive data like payment details and PCI compliance, which this rule addresses
Reasoning References