FAQ-000816 - External JavaScript Library Approval / Security Review Requirements

To meet security review requirements for third-party JavaScript libraries in managed packages, follow these comprehensive guidelines: **Core Requirements**: 1. **Static Resources**: Save third-party JavaScript files in the static resources folder of your package. This ensures code is under package version control and prevents unauthorized changes. 2. **Avoid Dynamic Loading**: Don't dynamically load JavaScript files from third-party endpoints like CDNs. This can introduce security risks as code may change without notice, potentially compromising the Salesforce org. 3. **Use `$Resource` URLs**: Reference JavaScript files using `$Resource` URLs within your package for secure and managed loading. 4. **Version Control**: Ensure your entire solution, including JavaScript files, is under version control to track changes and maintain package integrity. **CDN and External Loading Restrictions**: - JavaScript libraries loaded from CDNs aren't allowed in Salesforce security reviews - Exceptions are granted only for specific cases: Google Maps, Stripe libraries, and reCAPTCHA - For other cases, download the script and include it as a static resource in your package **Documentation Requirements**: 1. **Host in Static Resources**: Include JavaScript files in static resources folder and document their usage 2. **Document API Callouts**: Provide detailed documentation of JavaScript API callouts, including API details and credentials for testing endpoints 3. **Security Scan Reports**: Include security scan reports for JavaScript files and document any false positives with explanations 4. **Avoid Disallowed Contexts**: Don't use JavaScript in disallowed contexts such as Custom Objects Weblinks with JavaScript link type 5. **Submit Materials**: Include all relevant materials—static resources, security scan reports, and documentation—as part of security review submission **Evaluation and Preparation Steps**: 1. **Perform Security Scans**: Use tools like Salesforce Code Analyzer (e.g., RetireJS) to identify vulnerabilities. Replace flagged libraries with secure alternatives when possible. 2. **Document False Positives**: If a library is flagged but deemed secure, document the false positive with justifications 3. **Test Locker Service Compatibility**: Ensure library compatibility with Salesforce Locker Service 4. **Secure Coding Practices**: Avoid libraries with known vulnerabilities or outdated versions **Specific Library Requirements**: - **Popular Libraries** (FullCalendar, dhtmlx, D3): Check for vulnerabilities using platforms like Snyk, load from static resources, document usage of practices like `innerHTML` - **Visualforce Pages**: For pages loading external libraries, store libraries in static resources and reference using `$Resource` URLs **Evaluation Criteria**: 1. **Static Resources**: Include all scripts in static resources for full source code analysis 2. **Avoid Unsafe Inline Scripts**: Ensure library doesn't introduce XSS vulnerabilities 3. **Sanitize Dangerous Attributes**: Use secure filters for attributes like `iframe srcdoc`, `iframe src`, or `a href` 4. **LockerService Compatibility**: Ensure compatibility for Lightning apps API version 40 or later **Prohibited Practices**: - Dynamic code injection from third-party endpoints - Running JavaScript in Salesforce main app domain contexts - Using JSONP (use HTML5 CORS instead) - Loading from external domains without approved exceptions **Approval Process**: - Follow secure coding guidelines and avoid unsafe practices - Use recommended implementations (e.g., Lightning buttons instead of JavaScript on button clicks) - Document false positives thoroughly with detailed explanations - Provide comprehensive documentation including security scan reports By following these requirements, you'll ensure compliance with Salesforce's security guidelines and improve your chances of successful security review approval.

The original answer was comprehensive but contained some language that wasn't conversational enough per the brand guidelines. I made the following improvements: 1. **Conversational language**: Changed formal phrases like 'Do not dynamically load' to 'Don't dynamically load' and 'are not allowed' to 'aren't allowed' to match the conversational tone guidelines. 2. **Clearer action orientation**: Modified 'you ensure compliance' to 'you'll ensure compliance' to be more direct and action-focused. 3. **Improved scanning**: Made the text more scannable while preserving all original information and structure. Related Security Rules Selected: - **LoadJavaScriptHtmlScript** and **LoadJavaScriptIncludeScript**: Directly relate to the FAQ's core guidance about loading JavaScript libraries from static resources vs external sources - **AvoidCreateElementScriptLinkTag**: Connects to the FAQ's prohibition of dynamic code injection and unsafe script loading practices - **LibraryWithKnownCriticalSeverityVulnerability**, **LibraryWithKnownHighSeverityVulnerability**, **LibraryWithKnownMediumSeverityVulnerability**, **LibraryWithKnownLowSeverityVulnerability**: Directly support the FAQ's guidance on using RetireJS for vulnerability scanning and replacing flagged libraries - **AvoidJavaScriptCustomObject**, **AvoidJavaScriptWebLink**, **AvoidJavaScriptInUrls**: Support the FAQ's section on 'Prohibited Practices' and 'Avoid Disallowed Contexts' where it mentions Custom Objects Weblinks with JavaScript