FAQ-000456 - Custom Button and JavaScript Security / JavaScript Security Best Practices

Current Status:VALID_RESPONSEErrorUnable to AnswerSuggests Case

Current FAQ

Question
What are the security best practices and considerations when using JavaScript in custom buttons or when overriding standard buttons with custom components?
Answer
Here are the comprehensive security best practices for using JavaScript in custom buttons and when overriding standard buttons with custom components: ### Core Security Practices: 1. **Avoid Running JavaScript in the Main App Domain**: Do not run developer-written JavaScript directly in Salesforce's main app domain. 2. **Use Secure Alternatives**: Implement functionality using Visualforce, Aura, or Lightning Web Components instead of embedding JavaScript directly. 3. **Load JavaScript from Static Resources**: Always load JavaScript files from static resources within the app's namespace, not from third-party sources or external servers. 4. **Sandbox JavaScript Code**: Ensure the code is sandboxed and does not attempt to break out of its origin or namespace. 5. **Avoid REQUIRESCRIPT in Managed Packages**: Do not use REQUIRESCRIPT to inject JavaScript into the Salesforce origin, as it poses a security risk. ### Security Risk Mitigation: Using JavaScript in custom buttons can lead to security risks such as: - **Secure Coding Violations**: JavaScript executed in the Salesforce domain can interfere with other code. - **Cross-Site Scripting (XSS)**: Vulnerabilities that allow malicious scripts to execute. - **Unauthorized Access**: Breaking namespace isolation, a critical security measure. ### Data Protection and Input Validation: 1. **Protect Sensitive Data**: - Store sensitive data in protected custom settings or metadata. - Avoid logging sensitive information (e.g., passwords, keys, tokens) in debug statements. - Avoid exposing sensitive information unnecessarily. 2. **Validate and Encode User Inputs**: - Prevent vulnerabilities like SOQL injection and cross-site scripting (XSS) by validating and encoding all user inputs. - In Lightning Web Components (LWC) or Aura components, sanitize attribute values in the controller or renderer to avoid injecting unsafe attributes into the DOM. ### Access Controls and Secure Coding: 1. **Implement Proper Access Controls**: Use "user mode" for SOQL queries and DML operations to enforce CRUD/FLS checks. 2. **Secure Secrets and Tokens**: Follow guidelines for secure storage of secrets and tokens, ensuring all callback URLs use HTTPS. 3. **Regular Security Reviews**: Regularly review your code against the security review guide to identify and address potential vulnerabilities. 4. **Avoid JavaScript in the DOM**: Unless absolutely necessary, and ensure it is properly secured when used. These practices help maintain a secure and compliant Salesforce environment while ensuring a reliable user experience.
Enhancing FAQ...

Enhancing FAQ with AI recommendations...

AI Recommended Enhancement

Related Security Rules (click to view)
AvoidJavaScriptCustomObjectAvoidJavaScriptWebLinkAvoidJavaScriptInUrlsAvoidCreateElementScriptLinkTagLoadJavaScriptHtmlScriptLoadJavaScriptIncludeScriptApexXSSFromURLParamApexXSSFromEscapeFalseVfUnescapeElAvoidUnescapedHtmlInAura@lwc/lwc/no-inner-htmlApexSOQLInjectionApexCRUDViolation
Question
What are the security best practices and considerations when using JavaScript in custom buttons or when overriding standard buttons with custom components?
Recommended Answer Update
Here are the comprehensive security best practices for using JavaScript in custom buttons and when overriding standard buttons with custom components: ### Core Security Practices: 1. **Avoid Running JavaScript in the Main App Domain**: Don't run developer-written JavaScript directly in Salesforce's main app domain. 2. **Use Secure Alternatives**: Implement functionality using Visualforce, Aura, or Lightning Web Components instead of embedding JavaScript directly. 3. **Load JavaScript from Static Resources**: Always load JavaScript files from static resources within the app's namespace, not from third-party sources or external servers. 4. **Sandbox JavaScript Code**: Ensure the code is sandboxed and doesn't attempt to break out of its origin or namespace. 5. **Avoid REQUIRESCRIPT in Managed Packages**: Don't use REQUIRESCRIPT to inject JavaScript into the Salesforce origin, as it poses a security risk. ### Security Risk Mitigation: Using JavaScript in custom buttons can lead to security risks such as: - **Secure Coding Violations**: JavaScript executed in the Salesforce domain can interfere with other code. - **Cross-Site Scripting (XSS)**: Vulnerabilities that allow malicious scripts to execute. - **Unauthorized Access**: Breaking namespace isolation, a critical security measure. ### Data Protection and Input Validation: 1. **Protect Sensitive Data**: - Store sensitive data in protected custom settings or metadata. - Don't log sensitive information (e.g., passwords, keys, tokens) in debug statements. - Don't expose sensitive information unnecessarily. 2. **Validate and Encode User Inputs**: - Prevent vulnerabilities like SOQL injection and cross-site scripting (XSS) by validating and encoding all user inputs. - In Lightning Web Components (LWC) or Aura components, sanitize attribute values in the controller or renderer to prevent injecting unsafe attributes into the DOM. ### Access Controls and Secure Coding: 1. **Implement Proper Access Controls**: Use "user mode" for SOQL queries and DML operations to enforce CRUD/FLS checks. 2. **Secure Secrets and Tokens**: Follow guidelines for secure storage of secrets and tokens, ensuring all callback URLs use HTTPS. 3. **Regular Security Reviews**: Regularly review your code against the security review guide to identify and address potential vulnerabilities. 4. **Minimize JavaScript in the DOM**: Unless absolutely necessary, and ensure it's properly secured when used. These practices help maintain a secure and compliant Salesforce environment while ensuring a reliable user experience.
Reasoning
The FAQ content is accurate and comprehensive, requiring only minor refinements to improve clarity and tone. The main changes made: 1. **Tone adjustments**: Changed "Avoid logging" to "Don't log" and "avoid injecting" to "prevent injecting" for a more conversational tone as per guidelines. 2. **Clarity improvements**: Changed "Avoid JavaScript in the DOM" to "Minimize JavaScript in the DOM" to better reflect the nuanced guidance provided in the explanation. 3. **Minor wording refinements**: Changed "does not attempt" to "doesn't attempt" for consistency with conversational style. **Security Rules Selected:** - **AvoidJavaScriptCustomObject, AvoidJavaScriptWebLink, AvoidJavaScriptInUrls**: These rules directly relate to the FAQ's core message about avoiding JavaScript in custom buttons and web links, which is the primary focus of the question. - **AvoidCreateElementScriptLinkTag, LoadJavaScriptHtmlScript, LoadJavaScriptIncludeScript**: These rules relate to the FAQ's guidance on "Load JavaScript from Static Resources" and avoiding external JavaScript loading. - **ApexXSSFromURLParam, ApexXSSFromEscapeFalse, VfUnescapeEl, AvoidUnescapedHtmlInAura, @lwc/lwc/no-inner-html**: These XSS-related rules directly correspond to the FAQ's section on "Cross-Site Scripting (XSS)" risks and input validation/encoding guidance. - **ApexSOQLInjection**: This rule relates to the FAQ's mention of "SOQL injection" prevention in the input validation section. - **ApexCRUDViolation**: This rule corresponds to the FAQ's guidance on implementing proper access controls and using "user mode" for CRUD/FLS checks.
Reasoning References