FAQ-000853 - External Platform Security / External Web Applications and SaaS

Current Status:VALID_RESPONSEErrorUnable to AnswerSuggests Case

Current FAQ

Question
How do I address security alerts for external web applications that integrate with Salesforce?
Answer
To address security alerts for external web applications that integrate with Salesforce, follow these steps: 1. **Dynamic Code Loads**: Store JavaScript code in Salesforce static resources. Avoid linking or storing code on third-party servers. Use HTML5 CORS with specific domain whitelisting instead of wildcards. If dynamic content is needed, host it externally and iframe it into a Visualforce page. 2. **Session ID Usage**: Ensure session IDs do not leave the Salesforce org. If used internally (e.g., for Metadata services), document it as an acceptable use case. 3. **CRUD/FLS Enforcement**: Implement CRUD and FLS checks, especially for custom objects. Use tools like Salesforce Security Scanner, Checkmarx, or PMD to identify issues. For complex scenarios, consider using "user mode" to enforce security. 4. **Sensitive Data Handling**: Store sensitive data (e.g., secrets, credentials) in protected custom metadata or named credentials. Avoid exposing sensitive data in URLs or public objects. 5. **Static Resource Loading**: Use approved methods like `URLFOR()` or `/resource[/timestamp]/YourStaticResourceName` to load static resources. 6. **Vulnerability Mitigation**: Prioritize fixing high-severity vulnerabilities. For medium or low-severity findings, assess their impact and provide justifications for false positives. 7. **Security Review Preparation**: Follow secure coding practices and review the Salesforce Security Review Guide. Submit detailed documentation, including false positive justifications, to streamline the review process. By following these practices, you can mitigate risks and ensure compliance with Salesforce's security standards.
Enhancing FAQ...

Enhancing FAQ with AI recommendations...

AI Recommended Enhancement

Related Security Rules (click to view)
ApexCRUDViolationApexSharingViolationsAvoidApiSessionIdAvoidUnauthorizedApiSessionIdInApexAvoidUnauthorizedApiSessionIdInVisualforceAvoidUnauthorizedGetSessionIdInApexAvoidUnauthorizedGetSessionIdInVisualforceApexSuggestUsingNamedCredAvoidHardcodedCredentialsInFieldDeclsAvoidHardcodedCredentialsInHttpHeaderAvoidHardcodedCredentialsInVarAssignAvoidHardcodedCredentialsInVarDeclsLoadJavaScriptHtmlScriptLoadJavaScriptIncludeScriptAvoidCreateElementScriptLinkTagApexXSSFromURLParamVfUnescapeEl
Question
How do I address security alerts for external web applications that integrate with Salesforce?
Recommended Answer Update
To address security alerts for external web applications that integrate with Salesforce, follow these steps: 1. **Dynamic Code Loads**: Store JavaScript code in Salesforce static resources. Avoid linking or storing code on third-party servers. Use HTML5 CORS with specific domain whitelisting instead of wildcards. If dynamic content is needed, host it externally and iframe it into a Visualforce page. 2. **Session ID Usage**: Ensure session IDs don't leave the Salesforce org. If used internally (e.g., for Metadata services), document it as an acceptable use case. 3. **CRUD/FLS Enforcement**: Implement CRUD and FLS checks, especially for custom objects. For SOQL queries, use `WITH USER_MODE` to automatically enforce security. For Database methods, use `AccessLevel.USER_MODE` parameter. Use tools like Salesforce Security Scanner, Checkmarx, or PMD to identify issues. 4. **Sensitive Data Handling**: Store sensitive data (e.g., secrets, credentials) in protected custom metadata or named credentials. Avoid exposing sensitive data in URLs or public objects. 5. **Static Resource Loading**: Use approved methods like `URLFOR()` or `/resource[/timestamp]/YourStaticResourceName` to load static resources. 6. **Vulnerability Mitigation**: Prioritize fixing high-severity vulnerabilities. For medium or low-severity findings, assess their impact and provide justifications for false positives. 7. **Security Review Preparation**: Follow secure coding practices and review the Salesforce Security Review Guide. Submit detailed documentation, including false positive justifications, to streamline the review process. By following these practices, you can mitigate risks and ensure compliance with Salesforce's security standards.
Reasoning
I made two key improvements to align with modern security practices: 1. Updated CRUD/FLS enforcement guidance to prioritize modern `WITH USER_MODE` and `AccessLevel.USER_MODE` approaches over legacy manual checks, following the security approaches guidelines. 2. Changed 'do not' to 'don't' in the Session ID section to match the conversational tone guidelines. Related security rules selection reasoning: - ApexCRUDViolation & ApexSharingViolations: Directly relate to step 3's CRUD/FLS enforcement requirements - Session ID rules (AvoidApiSessionId, AvoidUnauthorizedApiSessionIdInApex, etc.): Apply to step 2's session ID usage restrictions - Credentials rules (ApexSuggestUsingNamedCred, AvoidHardcodedCredentialsInFieldDecls, etc.): Connect to step 4's sensitive data handling using named credentials - JavaScript loading rules (LoadJavaScriptHtmlScript, LoadJavaScriptIncludeScript, AvoidCreateElementScriptLinkTag): Relate to step 1's dynamic code loads and step 5's static resource loading - XSS rules (ApexXSSFromURLParam, VfUnescapeEl): Apply to step 4's guidance on not exposing sensitive data in URLs
Reasoning References
Recommended Related Articles