FAQ-001655 - Salesforce Platform Security Responsibility / XSS and Cross-Site Scripting Issues

Current Status:SUGGESTS_CASEErrorUnable to AnswerSuggests Case

Current FAQ

Question
How should I address XSS vulnerabilities that appear to be related to Salesforce platform functionality rather than my custom code?
Answer
**General Responsibility for Standard Salesforce Interface:** If a security vulnerability is found in a standard Salesforce interface, it is outside the scope of the AppExchange security review, which focuses on partner applications and their secure coding practices. Salesforce does not guarantee the security of any Partner Application, even those that pass the security review. Customers are responsible for evaluating the quality, security, and functionality of Partner Applications. **For Reflected XSS in Standard Interface:** If you believe a Reflected XSS vulnerability exists in Salesforce's standard interface, it is recommended to report the issue directly to Salesforce Support. Since this falls outside the scope of your custom code or the AppExchange security review, Salesforce will need to investigate and address the issue as part of their platform maintenance. Document the finding thoroughly and provide as much detail as possible when reporting it. **For Vulnerabilities in Standard Aura Components:** To address a vulnerability flagged in a standard Aura component during the AppExchange security review: 1. **Restrict Access**: Avoid using global access for Aura components unless absolutely necessary. Use more restrictive levels like `public` or `private` 2. **Control Exposure**: Ensure that `isExposed` is set to `false` if the component is exposed outside the namespace 3. **Prevent Clickjacking**: Use `position: relative` instead of `absolute` or `fixed` for nested components 4. **Secure Resources**: Avoid loading JavaScript or CSS directly from third-party sources. Include them as static resources in your package and reference them using `$Resource` 5. **Sanitize Inputs**: Validate and sanitize user inputs to prevent vulnerabilities like XSS or SOQL injection 6. **Document False Positives**: If the issue is a false positive, document your justification and submit it as part of the False Positive document during the review process **For XSS Related to Platform Functionality:** To address Cross-site Scripting (XSS) issues related to Salesforce platform functionality: 1. **Validate and Sanitize Inputs**: Ensure all user inputs are properly validated and sanitized before reflecting them back to the user 2. **Use Built-in Security Features**: Utilize Salesforce's built-in security features, such as the `<apex:outputText>` tag, which automatically escapes HTML and JavaScript 3. **Avoid Direct Embedding**: Refrain from directly embedding user inputs in Visualforce pages or Lightning components without proper encoding 4. **Secure External Integrations**: Validate and sanitize any data passed to the Salesforce platform from external sources 5. **Implement Content Security Policy (CSP)**: Use CSP headers to further mitigate risks **For Stored XSS Through Standard Platform UI:** To address a Stored XSS vulnerability triggered through the standard Salesforce platform UI: 1. **Encode User Inputs**: Ensure all user inputs are properly encoded before being rendered in the UI. Use Salesforce's built-in security features like the `escapeHtml4()` method or similar encoding mechanisms to sanitize dynamic content 2. **Review Data Flow**: Confirm that no untrusted input is being stored or displayed without proper validation and encoding 3. **Submit a Case**: If the issue persists, consider submitting a case with detailed information for further guidance **For XSS on Standard Record Pages:** To address XSS vulnerabilities reported on standard Salesforce record pages: 1. **Encoding and Sanitization**: - For Visualforce pages, ensure all merge fields are auto HTML encoded unless `escape="false"` is explicitly required - If `escape="false"` is used, encode the output in the controller using functions like `JSENCODE`, `JSINHTMLENCODE`, `HTMLENCODE`, or `URLENCODE` 2. **Lightning Components**: - Sanitize attribute values in the controller or renderer to prevent unsafe attributes like `href` or `src` from being exploited - Avoid using `innerHTML` or similar methods that directly inject user data into the DOM without sanitization 3. **Documentation**: Document any mitigations or justifications in a false-positive document if applicable **For XSS in Standard Salesforce Functionality:** When a security review identifies XSS vulnerabilities in standard Salesforce functionality: 1. **Implement Output Encoding and Sanitization**: - For Visualforce pages, ensure all merge fields are HTML encoded unless explicitly required otherwise - Avoid using the `escape="false"` attribute unless the output is correctly encoded in the controller 2. **Sanitize Lightning Components**: - Sanitize attribute values in the controller or renderer to prevent unsafe attributes like `href` or `src` from being exploited - Use encoding functions such as `JSENCODE`, `HTMLENCODE`, or `URLENCODE` where applicable 3. **Document Mitigations**: If the vulnerability is deemed non-exploitable, document any mitigations or justifications in a false-positive document For additional help, you can schedule a technical office hours appointment with the Product Security team through the Partner Security Portal.
Enhancing FAQ...

Enhancing FAQ with AI recommendations...

AI Recommended Enhancement

Related Security Rules (click to view)
ApexXSSFromEscapeFalseVfUnescapeElAvoidUnescapedHtmlInAura
Question
How should I address XSS vulnerabilities that appear to be related to Salesforce platform functionality rather than my custom code?
Recommended Answer Update
**General Responsibility for Standard Salesforce Interface:** If a security vulnerability is found in a standard Salesforce interface, it's outside the scope of the AppExchange security review, which focuses on partner applications and their secure coding practices. Salesforce doesn't guarantee the security of any Partner Application, even those that pass the security review. Customers are responsible for evaluating the quality, security, and functionality of Partner Applications. **For Reflected XSS in Standard Interface:** If you believe a Reflected XSS vulnerability exists in Salesforce's standard interface, report the issue directly to Salesforce Support. Since this falls outside the scope of your custom code or the AppExchange security review, Salesforce will need to investigate and address the issue as part of their platform maintenance. Document the finding thoroughly and provide as much detail as possible when reporting it. **For Vulnerabilities in Standard Aura Components:** To address a vulnerability flagged in a standard Aura component during the AppExchange security review: 1. **Restrict Access**: Avoid using global access for Aura components unless absolutely necessary. Use more restrictive levels like `public` or `private` 2. **Control Exposure**: Ensure that `isExposed` is set to `false` if the component is exposed outside the namespace 3. **Prevent Clickjacking**: Use `position: relative` instead of `absolute` or `fixed` for nested components 4. **Secure Resources**: Avoid loading JavaScript or CSS directly from third-party sources. Include them as static resources in your package and reference them using `$Resource` 5. **Sanitize Inputs**: Validate and sanitize user inputs to prevent vulnerabilities like XSS or SOQL injection 6. **Document False Positives**: If the issue is a false positive, document your justification and submit it as part of the False Positive document during the review process **For XSS Related to Platform Functionality:** To address Cross-site Scripting (XSS) issues related to Salesforce platform functionality: 1. **Validate and Sanitize Inputs**: Ensure all user inputs are properly validated and sanitized before reflecting them back to the user 2. **Use Built-in Security Features**: Utilize Salesforce's built-in security features, such as the `<apex:outputText>` tag, which automatically escapes HTML and JavaScript 3. **Avoid Direct Embedding**: Don't directly embed user inputs in Visualforce pages or Lightning components without proper encoding 4. **Secure External Integrations**: Validate and sanitize any data passed to the Salesforce platform from external sources 5. **Implement Content Security Policy (CSP)**: Use CSP headers to further mitigate risks **For Stored XSS Through Standard Platform UI:** To address a Stored XSS vulnerability triggered through the standard Salesforce platform UI: 1. **Encode User Inputs**: Ensure all user inputs are properly encoded before being rendered in the UI. Use Salesforce's built-in security features like the `escapeHtml4()` method or similar encoding mechanisms to sanitize dynamic content 2. **Review Data Flow**: Confirm that no untrusted input is being stored or displayed without proper validation and encoding 3. **Submit a Case**: If the issue persists, consider submitting a case with detailed information for further guidance **For XSS on Standard Record Pages:** To address XSS vulnerabilities reported on standard Salesforce record pages: 1. **Encoding and Sanitization**: - For Visualforce pages, ensure all merge fields are auto HTML encoded unless `escape="false"` is explicitly required - If `escape="false"` is used, encode the output in the controller using functions like `JSENCODE`, `JSINHTMLENCODE`, `HTMLENCODE`, or `URLENCODE` 2. **Lightning Components**: - Sanitize attribute values in the controller or renderer to prevent unsafe attributes like `href` or `src` from being exploited - Avoid using `innerHTML` or similar methods that directly inject user data into the DOM without sanitization 3. **Documentation**: Document any mitigations or justifications in a false-positive document if applicable **For XSS in Standard Salesforce Functionality:** When a security review identifies XSS vulnerabilities in standard Salesforce functionality: 1. **Implement Output Encoding and Sanitization**: - For Visualforce pages, ensure all merge fields are HTML encoded unless explicitly required otherwise - Avoid using the `escape="false"` attribute unless the output is correctly encoded in the controller 2. **Sanitize Lightning Components**: - Sanitize attribute values in the controller or renderer to prevent unsafe attributes like `href` or `src` from being exploited - Use encoding functions such as `JSENCODE`, `HTMLENCODE`, or `URLENCODE` where applicable 3. **Document Mitigations**: If the vulnerability is deemed non-exploitable, document any mitigations or justifications in a false-positive document For additional help, you can schedule a technical office hours appointment with the Product Security team through the Partner Security Portal.
Reasoning
The FAQ content was improved for conversational tone and clarity while preserving all information and structure. Key changes include: using contractions ('it's', 'doesn't', 'don't') for a more conversational tone, removing unnecessary formal language like 'it is recommended to' in favor of direct instructions, and improving readability without changing the technical content or recommendations. All security guidance and technical details remain intact. Regarding security rules selection: ApexXSSFromEscapeFalse was selected because the FAQ extensively discusses the use of escape="false" in Visualforce pages and the need for proper encoding when this attribute is used. VfUnescapeEl was chosen as it directly relates to the FAQ's guidance on encoding merge fields and avoiding unescaped content in Visualforce pages. AvoidUnescapedHtmlInAura was included because the FAQ provides detailed guidance on sanitizing Aura/Lightning components and avoiding innerHTML usage, which directly corresponds to this rule's purpose of preventing unescaped HTML in Aura components.
Reasoning References