FAQ-001144 - Lightning Web Components and JavaScript Security / Third-Party Libraries and External APIs

To prepare for potential security review findings involving Lightning Web Components (LWC) and external API integrations, follow these steps: 1. **CRUD/FLS Enforcement**: Implement CRUD and FLS checks for all DML operations. Use `AccessLevel.USER_MODE` for Database methods or `WITH USER_MODE` for SOQL queries to automatically enforce permissions. 2. **Secure Sensitive Data**: Store sensitive information like API keys or secrets in Named Credentials, protected custom settings, or custom metadata. Avoid hardcoding sensitive data in your code. 3. **Static Resources**: Include all static resources (e.g., JavaScript files) in the package as static resources. Avoid dynamically loading external resources. 4. **Third-Party Integrations**: Submit scan reports for third-party integrations, provide authentication credentials, and include API documentation. Ensure sensitive data transmission complies with security standards. 5. **OAuth Implementation**: Request only necessary permissions for OAuth flows. Store OAuth secrets securely in Named Credentials, protected custom settings, or custom metadata. Use HTTPS for callback URLs. 6. **Light DOM and Iframes**: Avoid using Light DOM components if possible, as they may not pass security reviews. Ensure hosted applications in iframes meet security requirements. 7. **Testing and Documentation**: Conduct end-to-end testing and document your implementation thoroughly. Explain any false positives in scan reports. 8. **Use Security Tools**: Utilize tools like the Source Code Analyzer and PMD scanner to identify and address security issues. Resolve high-severity findings and document false positives. By following these steps, you can address potential security concerns and align with Salesforce's security standards.

The FAQ content is mostly current and comprehensive, but I made two key improvements: 1) Updated the security approach guidance to prioritize modern features as per guidelines - changed 'USER_MODE approach' to specifically mention 'AccessLevel.USER_MODE for Database methods or WITH USER_MODE for SOQL queries' to be more precise about modern enforcement methods, and 2) Enhanced the credential storage recommendations to lead with Named Credentials, which is the preferred modern approach for API credentials and OAuth secrets. These changes align with current best practices while preserving all existing information. For security rules selection: ApexCRUDViolation and ApexSharingViolations relate to point 1 about CRUD/FLS enforcement. Multiple hardcoded credentials rules (AvoidHardcodedCredentialsInFieldDecls, AvoidHardcodedCredentialsInVarDecls, AvoidHardcodedCredentialsInVarAssign, AvoidHardcodedCredentialsInHttpHeader) and ProtectSensitiveData relate to point 2 about securing sensitive data. ApexSuggestUsingNamedCred directly supports the Named Credentials recommendation. ApexInsecureEndpoint, UseHttpsCallbackUrlConnectedApp, and LimitConnectedAppScope relate to points 4-5 about API integrations and OAuth security. The Load* rules (LoadJavaScriptIncludeScript, LoadJavaScriptHtmlScript, LoadCSSLinkHref, LoadCSSApexStylesheet) relate to point 3 about static resources and avoiding dynamic loading of external resources.