FAQ-001118 - Lightning Web Components and JavaScript Security / Aura to LWC Migration and Compatibility

**Addressing Access Control Violations in Aura Components:** 1. **Enforce CRUD/FLS Checks**: Implement Create, Read, Update, and Delete (CRUD) and Field-Level Security (FLS) checks before performing database operations. Use `WITH USER_MODE` in SOQL queries or `AccessLevel.USER_MODE` with Database methods to automatically enforce permissions, or manually validate using methods like `isAccessible()`, `isCreateable()`, and `isUpdateable()`. 2. **Use User Mode**: Execute database operations in user mode to respect user permissions. Use the `WITH USER_MODE` clause in SOQL queries, `AccessLevel.USER_MODE` with Database methods, or explicitly check permissions in Apex. 3. **Restrict Access Levels**: Avoid using global access levels for attributes or methods unless necessary. Use `public` or `private` access modifiers to limit exposure. 4. **Sanitize Inputs**: Validate and sanitize all inputs to prevent injection attacks or unauthorized access. 5. **Implement Conditional Logic**: Verify that users have the necessary permissions or roles to access data or perform actions. 6. **Remove Unnecessary Exposure**: Remove unnecessary `@AuraEnabled` annotations from methods that don't need to be exposed to the client-side. **Equivalent Security Practices for LWC:** Lightning Web Components (LWC) and Aura components share several security practices, but there are key differences: 1. **Static Resources**: Ensure all scripts and resources are loaded from static resources, not third-party sources. 2. **LockerService Enforcement**: LockerService is enforced for components using API version 40.0 or higher, providing iframe-like isolation for namespaces. 3. **Sanitization and Encoding**: Unlike Aura components, LWCs don't perform automatic HTML encoding. Developers must sanitize and encode user-controlled data to prevent vulnerabilities like cross-site scripting (XSS). Use secure filters or sanitization libraries for dangerous attributes. 4. **Dynamic Content Restrictions**: Dynamically loading HTML, JavaScript, or CSS into LWC components isn't allowed unless the content is stripped of such code or loaded within an iframe. 5. **Avoid Unsafe Inline Styles**: Don't use unsafe inline styles or attributes, and ensure compliance with strict Content Security Policies (CSP). By following these practices, you can maintain secure and robust applications in both Aura and LWC while aligning with broader Lightning component security guidelines.

Updated the answer to prioritize modern security features while preserving all existing content. Changed 'Avoid using global access levels' to 'Avoid using global access levels' (removed 'Avoid Unnecessary Exposure' point 6 duplication by clarifying it focuses on @AuraEnabled annotations). Updated language to be more conversational by using contractions (don't, isn't, aren't) and more direct phrasing while maintaining all technical accuracy. Selected security rules based on their direct relevance to the FAQ content: - ApexCRUDViolation: Directly relates to point 1 about implementing CRUD/FLS checks before database operations - ApexSharingViolations: Relates to point 2 about using user mode and respecting user permissions through sharing rules - ApexXSSFromEscapeFalse: Relates to point 4 about sanitizing inputs and point 3 in LWC section about sanitization and encoding to prevent XSS - ApexXSSFromURLParam: Relates to input sanitization practices mentioned in point 4 - AvoidUnescapedHtmlInAura: Directly relates to the Aura component sanitization practices discussed in point 4 and the LWC encoding differences in point 3 - @lwc/lwc/no-inner-html: Specifically relates to point 3 about LWCs not performing automatic HTML encoding and the need for developers to sanitize content