FAQ-000445 - Content Security Policy and CSP / CSP Security Review Requirements

Content Security Policy (CSP) requirements for Salesforce security review: **CSP Mandatory Status:** A Content Security Policy (CSP) isn't explicitly mandatory for passing the Salesforce security review. However, implementing a strong CSP is highly recommended as it helps protect against vulnerabilities like Cross-Site Scripting (XSS). **When CSP Violations Are Acceptable:** CSP violations are acceptable if there are no Cross-Site Scripting (XSS) vulnerabilities present, as this is explicitly checked during the review process. However, you'll need to ensure that other security protections are in place and that the absence of XSS vulnerabilities is verified. **'Unsafe-inline' Guidelines:** - Content Security Policy violations for 'unsafe-inline' CSS styles aren't acceptable for Salesforce security review - The use of 'unsafe-inline' in a CSP isn't always a blocker for passing the security review, but it's discouraged due to security risks - If 'unsafe-inline' is used, you must ensure that no vulnerabilities, such as Cross-Site Scripting (XSS), exist in the source code - For external websites: A CSP containing 'unsafe-inline' on an external website doesn't directly prevent a Salesforce package from passing security review, but it's still discouraged **Recommendations:** - Implement a strict CSP and avoid 'unsafe-inline' whenever possible - Use secure alternatives like referencing CSS from static resources or using `<ltng:require>` in Lightning components - Remember that CSP serves as an additional layer of protection rather than a substitute for secure coding practices - Category: Content Security Policy and CSP - Subcategory: CSP Security Review Requirements

The main recommendations focus on improving the conversational tone by using contractions ("isn't" instead of "is not", "aren't" instead of "are not", "doesn't" instead of "does not", "you'll" instead of "you will") to make the content more accessible and friendly while maintaining the technical accuracy. The original content was well-structured and accurate, so no major changes were needed. For the related security rules, I selected rules that directly relate to XSS prevention since this FAQ discusses CSP as protection against XSS vulnerabilities: 1. **ApexXSSFromEscapeFalse** - This rule detects XSS vulnerabilities from unescaped output, which directly relates to the FAQ's discussion of CSP protecting against XSS and the need to verify "no Cross-Site Scripting (XSS) vulnerabilities exist in the source code" 2. **ApexXSSFromURLParam** - This rule identifies XSS from URL parameters, which is relevant to the FAQ's emphasis on ensuring XSS vulnerabilities are absent when CSP violations are present 3. **VfUnescapeEl** - This rule catches unescaped expressions in Visualforce that can lead to XSS, directly connecting to the FAQ's discussion of XSS prevention and the statement that "CSP violations are acceptable if there are no Cross-Site Scripting (XSS) vulnerabilities present" 4. **VfHtmlStyleTagXss** - This rule specifically addresses XSS in HTML style tags, which relates to the FAQ's discussion of 'unsafe-inline' CSS styles and the security risks they pose 5. **AvoidUnescapedHtmlInAura** - This rule prevents XSS in Aura components through unescaped HTML, connecting to the FAQ's mention of Lightning components and secure alternatives like `<ltng:require>`