FAQ-001646 - Salesforce Platform Security Responsibility / Platform Responsibility and Remediation

Current Status:SUGGESTS_CASEErrorUnable to AnswerSuggests Case

← Back to List View Prompt Template

Current FAQ

Question
What should I do when security vulnerabilities are found in standard Salesforce components, platform-provided functionality, or system-provided classes?
Answer
When security vulnerabilities are found in standard Salesforce components or platform-provided functionality: **For Standard Components or Pages Hosting Your Component:** 1. **Identify the Vulnerability**: Understand the specific issue and its context within the component or page 2. **Implement Security Measures**: - Ensure all JavaScript code is stored in static resources, avoid JSONP, and use HTML5 CORS with specific domains - Implement proper CRUD/FLS checks for data access and manipulation - Ensure session IDs or sensitive data are not exposed outside the org - Follow secure coding practices for XSS/CSRF vulnerabilities 3. **Use Security Tools**: Use tools like the SFCA scanner to identify and address issues 4. **Test Thoroughly**: Test all fixes before resubmitting the component or package for review **For System-Provided Classes:** If the security scanner flags a vulnerability in a standard system-provided class, document the flagged issue as a false positive. Provide a detailed explanation in the false positive document, clarifying why the flagged vulnerability is not applicable or exploitable in your use case. **For Platform-Provided Functionality:** 1. **Document the Issue**: Clearly document the issue and provide a detailed explanation in a false positive (FP) document 2. **Include Context**: Include any relevant use cases to help reviewers understand the context 3. **Provide Evidence**: If the issue is related to functionality outside your control, include evidence or explanations in your false-positive documentation 4. **Follow Security Guidelines**: Ensure compliance with Salesforce's security guidelines and provide any necessary evidence to demonstrate this **For Standard Scanner Findings:** 1. **Review the Findings**: Analyze the scanner report to determine if the vulnerabilities are true positives or false positives 2. **Document False Positives**: Create a detailed false positive document with screenshots, explanations, and justifications 3. **Fix True Positives**: For valid vulnerabilities, implement necessary fixes such as securing sensitive information storage and ensuring proper CRUD/FLS checks 4. **Use Automated Tools**: Leverage tools like PMD, SFCA, or SFDX scanners to identify and address similar issues 5. **Follow Security Guidelines**: Adhere to Salesforce security best practices 6. **Resubmit for Review**: After addressing issues, resubmit your application with the false positive document and relevant reports **When to Open a Case:** For most platform-related security issues, you should open a support case with Salesforce to seek further guidance or clarification. This is especially important when you need confirmation that an issue is a platform limitation or when you require additional assistance in addressing the findings.

Enhancing FAQ with AI recommendations...

AI Recommended Enhancement

Related Security Rules (click to view)
ApexCRUDViolationApexSharingViolationsApexXSSFromEscapeFalseApexXSSFromURLParamApexCSRFVfCsrfVfUnescapeElAvoidApiSessionIdAvoidUnauthorizedApiSessionIdInApexAvoidUnauthorizedGetSessionIdInApex
Question
What should I do when security vulnerabilities are found in standard Salesforce components, platform-provided functionality, or system-provided classes?
Recommended Answer Update
When security vulnerabilities are found in standard Salesforce components or platform-provided functionality: **For Standard Components or Pages Hosting Your Component:** 1. **Identify the Vulnerability**: Understand the specific issue and its context within the component or page 2. **Implement Security Measures**: - Store all JavaScript code in static resources, avoid JSONP, and use HTML5 CORS with specific domains - Implement proper CRUD/FLS checks for data access and manipulation - Ensure session IDs or sensitive data aren't exposed outside the org - Follow secure coding practices for XSS/CSRF vulnerabilities 3. **Use Security Tools**: Use tools like the SFCA scanner to identify and address issues 4. **Test Thoroughly**: Test all fixes before resubmitting the component or package for review **For System-Provided Classes:** If the security scanner flags a vulnerability in a standard system-provided class, document the flagged issue as a false positive. Provide a detailed explanation in the false positive document, clarifying why the flagged vulnerability isn't applicable or exploitable in your use case. **For Platform-Provided Functionality:** 1. **Document the Issue**: Clearly document the issue and provide a detailed explanation in a false positive (FP) document 2. **Include Context**: Include any relevant use cases to help reviewers understand the context 3. **Provide Evidence**: If the issue relates to functionality outside your control, include evidence or explanations in your false-positive documentation 4. **Follow Security Guidelines**: Ensure compliance with Salesforce's security guidelines and provide any necessary evidence to demonstrate this **For Standard Scanner Findings:** 1. **Review the Findings**: Analyze the scanner report to determine if the vulnerabilities are true positives or false positives 2. **Document False Positives**: Create a detailed false positive document with screenshots, explanations, and justifications 3. **Fix True Positives**: For valid vulnerabilities, implement necessary fixes such as securing sensitive information storage and ensuring proper CRUD/FLS checks 4. **Use Automated Tools**: Leverage tools like PMD, SFCA, or SFDX scanners to identify and address similar issues 5. **Follow Security Guidelines**: Adhere to Salesforce security best practices 6. **Resubmit for Review**: After addressing issues, resubmit your application with the false positive document and relevant reports **When to Open a Case:** For most platform-related security issues, you should open a support case with Salesforce to seek further guidance or clarification. This is especially important when you need confirmation that an issue is a platform limitation or when you require additional assistance in addressing the findings.
Reasoning
The FAQ content was improved to enhance clarity and readability by: 1) Simplifying language (removing 'ensure' redundancy, using contractions like 'aren't' and 'isn't', replacing 'is related to' with simpler 'relates to'); 2) Making the content more conversational and positive by removing passive constructions and improving flow; 3) Maintaining all original technical points and structure while making the text more scannable and direct. No outdated content was detected as the security practices align with current requirements. Regarding security rules selected: ApexCRUDViolation and ApexSharingViolations relate to the FAQ's discussion of 'proper CRUD/FLS checks for data access and manipulation' which directly corresponds to these rules' purposes. ApexXSSFromEscapeFalse, ApexXSSFromURLParam, ApexCSRF, VfCsrf, and VfUnescapeEl all relate to the FAQ's mention of 'secure coding practices for XSS/CSRF vulnerabilities' as these rules detect and prevent cross-site scripting and cross-site request forgery attacks. AvoidApiSessionId, AvoidUnauthorizedApiSessionIdInApex, and AvoidUnauthorizedGetSessionIdInApex relate to the FAQ's guidance about ensuring 'session IDs or sensitive data aren't exposed outside the org' as these rules specifically detect unauthorized session ID usage and exposure.
Reasoning References
Recommended Related Articles