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

To prevent JavaScript DOM vulnerabilities in Salesforce applications, follow these secure coding practices: - **Sandbox JavaScript Code**: Ensure JavaScript runs in its proper origin using Visualforce, Aura, or Lightning Web Components. Avoid running JavaScript outside the designated namespace or breaking out of the sandbox. - **Sanitize Inputs**: Sanitize all inputs, including URL parameters, to prevent injection attacks. - **Avoid Third-Party JavaScript**: Don't dynamically load JavaScript files from third-party endpoints. Instead, store and load them from static resources within your package. - **Sanitize Attributes**: Ensure attributes like `href` or `src` are sanitized in controllers or renderers to prevent unsafe data injection into the DOM. - **Use Encoding Functions**: Apply encoding functions like `JSENCODE`, `HTMLENCODE`, or `URLENCODE` where applicable. - **No Direct DOM Manipulation**: Avoid using methods like `document.createElement` or executing JavaScript directly in the Salesforce domain. Following these practices ensures compliance with secure coding standards and minimizes security risks.

The original content is accurate and comprehensive but needed minor improvements in tone and clarity while preserving all existing points. Changed 'Do not dynamically load' to 'Don't dynamically load' to match conversational style guidelines. The content directly aligns with multiple security rules: - **AvoidCreateElementScriptLinkTag**: The FAQ's point about avoiding 'document.createElement' directly corresponds to this rule which flags dynamic creation of script and link elements that could lead to XSS vulnerabilities. - **ApexXSSFromURLParam**: The FAQ's guidance on sanitizing URL parameters directly relates to this rule which detects XSS vulnerabilities from URL parameters. - **ApexXSSFromEscapeFalse**: The recommendation to use encoding functions (JSENCODE, HTMLENCODE, URLENCODE) aligns with this rule that flags unescaped output that could lead to XSS. - **AvoidUnescapedHtmlInAura**: The FAQ's emphasis on sanitizing inputs and outputs in Aura components relates to this rule about unescaped HTML in Aura. - **@lwc/lwc/no-inner-html**: The guidance against direct DOM manipulation applies to LWC components covered by this ESLint rule. - **LoadJavaScriptHtmlScript and LoadJavaScriptIncludeScript**: The FAQ's advice about avoiding third-party JavaScript loading and using static resources instead directly relates to these rules that flag external script loading vulnerabilities.