FAQ-001128 - Lightning Web Components and JavaScript Security / DOM Manipulation and Injection Vulnerabilities

Dynamically creating and injecting Lightning Web Components (LWCs) can introduce several security risks: 1. **Cross-Site Scripting (XSS)**: If user-controlled data is injected into the DOM without proper sanitization or encoding, it can lead to XSS vulnerabilities. This is especially risky when using directives like `lwc:dom="manual"`, which bypass the framework's default protections. 2. **Code Interference**: JavaScript from multiple vendors running in the same origin can interfere with each other. To prevent this, vendor JavaScript is sandboxed, and breaking out of this sandbox is a secure coding violation. 3. **Dynamic Content Risks**: Dynamically loading HTML, JavaScript, or CSS into components isn't allowed for AppExchange security reviews unless the content is stripped of executable code. This ensures that externally managed code can't introduce vulnerabilities. 4. **Lack of Auto-Encoding**: Unlike Visualforce, the Lightning framework doesn't automatically encode HTML. Developers must manually sanitize or encode data to prevent injection attacks. 5. **Lightning Locker Service Compliance**: Lightning components must comply with Lightning Locker Service, which enforces strict security boundaries. Disabling or bypassing these protections is a security violation. To mitigate these risks, developers should sanitize and encode all user-controlled data, avoid dynamically loading external scripts or styles, and follow Salesforce's secure coding guidelines.

Updated language to be more conversational and direct by using contractions ("isn't," "can't," "doesn't") and more natural phrasing ("Lightning Locker Service" instead of just "LockerService") to align with the brand guidelines. These changes improve clarity while maintaining all original technical content and structure. Regarding security rules selection: 1. **AvoidAuraWithLockerDisabled**: This rule directly relates to point 5 in the FAQ about "LockerService Compliance" and the requirement that Lightning components must comply with security boundaries. The FAQ specifically mentions that "disabling or bypassing LockerService protections is a security violation," which is exactly what this rule detects. 2. **AvoidUnescapedHtmlInAura**: This rule connects to points 1 and 4 in the FAQ about XSS risks and lack of auto-encoding. The FAQ discusses how "user-controlled data injected into the DOM without proper sanitization" leads to XSS vulnerabilities and that "developers must manually sanitize or encode data," which is precisely what this rule enforces. 3. **@lwc/lwc/no-inner-html**: This ESLint rule directly addresses the XSS concerns mentioned in point 1 of the FAQ regarding user-controlled data injection into the DOM. The FAQ's discussion of XSS risks from improper DOM manipulation is exactly what this rule prevents. 4. **AvoidCreateElementScriptLinkTag**: This rule relates to point 3 about "dynamically loading HTML, JavaScript, or CSS into components" being prohibited for AppExchange reviews. The rule prevents dynamic creation of script and link tags, which aligns with the FAQ's warning about externally managed code introducing vulnerabilities.