FAQ-000814 - External JavaScript Library Approval / General Requirements and Best Practices

To include third-party JavaScript libraries in managed packages, follow these comprehensive requirements and best practices: **Core Requirements**: 1. **Store in Static Resources**: Libraries must be saved in the static resources folder of the package to ensure version control and compliance with security standards. 2. **No Dynamic Loading**: Dynamically loading JavaScript files from third-party endpoints, such as CDNs, is not allowed, except for specific approved libraries like Google Maps and Stripe. 3. **Use `$Resource` URLs**: Load the static resources using `$Resource` URLs in your code for secure referencing. 4. **Version Control**: Ensure all JavaScript libraries are versioned with a package version ID for tracking and compliance. **Security Best Practices**: 1. **Sandboxing**: Keep JavaScript code within its namespace sandbox and avoid running code outside the designated origin. 2. **Secure Communication**: Use HTTPS for JavaScript-based API callouts and avoid insecure protocols like HTTP. 3. **Regular Updates**: Use the latest secure versions of libraries, replacing outdated or vulnerable ones. If no secure version exists, consider alternative libraries. 4. **Static Analysis**: Use tools like Salesforce Code Analyzer to scan for vulnerabilities, address flagged issues, and document false positives. 5. **Vulnerability Checks**: Ensure all third-party libraries are free from publicly listed vulnerabilities using tools like Snyk or RetireJS. **Documentation Requirements**: 1. **Document API Callouts**: If libraries involve JavaScript-based API callouts, document them thoroughly and provide necessary credentials for testing during security review. 2. **API Details**: Share API details and credentials during app submission for security review. **Acceptable vs. Prohibited Usage**: **Acceptable**: - Static hosting within package's static resources - Using `<apex:includeScript>` to load JavaScript resources on Visualforce pages when hosted statically - JavaScript-based API callouts (when properly documented) **Violations**: - Dynamic loading from third-party endpoints or CDNs - Attempting to break out of the sandbox and run code outside the origin - Using JavaScript in Custom Object Weblinks or injecting scripts into Salesforce origin via REQUIRESCRIPT in managed packages **Dynamic Parameters**: When including libraries with dynamic parameters: - JavaScript code must still be stored in static resources - If dynamic content is necessary, host it externally and embed into Visualforce page using iframe (not associated with Salesforce domain) - Any JavaScript-based API callouts must be thoroughly documented These practices help mitigate risks, ensure compliance with Salesforce's security standards, and meet AppExchange Security Review requirements.

The FAQ content is accurate and comprehensive but needed a minor update. The only change made was updating the vulnerability checking tool reference from 'Snyk' to 'Snyk or RetireJS' to be more accurate since RetireJS is specifically mentioned in the security rules. All other content remains unchanged as it accurately reflects current requirements and best practices. The security rules selected are all directly relevant to the FAQ content: LoadJavaScriptIncludeScript and LoadJavaScriptHtmlScript detect external JavaScript loading which the FAQ discusses as prohibited. AvoidCreateElementScriptLinkTag prevents dynamic script creation which the FAQ specifically mentions as a violation. AvoidJavaScriptWebLink and AvoidJavaScriptCustomObject prevent JavaScript usage in weblinks and custom objects which the FAQ lists as violations. The LibraryWithKnown*Vulnerability rules (all severity levels) detect vulnerable libraries, which directly relates to the FAQ's emphasis on vulnerability checking and using secure versions of libraries.