ISVforce Guide

Clouds with binary code floating aboveCloud with binary code floating above

No Results

Search Tips:

  • Please consider misspellings
  • Try different search keywords
ISVforce Guide: Build and Distribute AppExchange Solutions
Get Ready to Distribute on AppExchange
Use Managed Packages to Develop Your AppExchange Solution
Manage Orgs with Environment Hub
Architectural Considerations for Group and Professional Editions
Security Requirements for AppExchange Partners and Solutions
Security Policy Requirements
Prevent Secure Coding Violations
Load JavaScript Files from Third-Party Endpoints
Load Third-Party CSS in Lightning Components
Use CSS Outside Components
Running JavaScript in the Salesforce Domain
Expose Secret Data When Debugging
Store Sensitive Data Insecurely
Using Software That Has Known Vulnerabilities
Use Sample Code in Production
Bypass Object-Level and Field-Level Access Settings
Bypass Sharing Rules in Apex
SOQL Injection Due to Insecure Database Query Construction
Cross-Site Request Forgery
Open Redirects
Lightning LockerService Disabled
Insufficient Escaping in Lightning Components
Asynchronous Code in Components
Secure Communication
Secure Your B2C Commerce Solution
Secure Your Tableau Accelerator
Pass the AppExchange Security Review
Manage Your AppExchange Listings
Sell on AppExchange with Checkout
Report Orders to Salesforce with the Channel Order App
Provide Free Trials of Your AppExchange Solution
OEM User License Guide
PDF

Running JavaScript in the Salesforce Domain

JavaScript code from multiple vendors can run in the same origin. To prevent code interference, vendor JavaScript code is sandboxed. Don’t attempt to break out of a sandbox or run code outside your origin. Use Visualforce, Aura, or Lightning Web Components, which run in the proper origin.

Many different types of JavaScript code run in a Salesforce org, including unpackaged customer code, Salesforce code, and packaged code. Typically, the code is from multiple vendors that have no way of collaborating with each other. If their code runs in the same origin, code from one vendor can interfere with other vendors’ code.

To prevent code interference, vendor JavaScript code is sandboxed. With Visualforce solutions, JavaScript code is sandboxed in unique, vendor-specific origins. With Lightning solutions and Lightning Web Components (LWCs), JavaScript is sandboxed in unique, vendor-specific lockers.

Any attempt to break out of a sandbox and run code outside your origin is a secure coding violation. A secure coding violation includes attempts to run vendor-written JavaScript code in the Salesforce origin via homepage components, web links, or custom buttons.

In most situations, you can achieve the same functionality by using Visualforce, Aura, or Lightning Web Components, which run in the proper origin.

Metadata Example

The metadata in this example represents a custom object. A web link within this custom object is defined using the REQUIRESCRIPT statement. In a managed package, using REQUIRESCRIPT is a security vulnerability because the vendor is injecting its code into a Salesforce origin. Managed packages must stay within their namespace sandbox and can’t execute scripts outside this sandbox.
<?xml version=”1.0”encoding="UTF-8"?>
<CustomObject xmlns="http://soap.sforce.com/2006/04/metadata">
<actionOverrides>
<actionName>Accept</actionName>
      <type>Default</type>
</actionOverrides>
<webLinks>
     <fullName>Add_to_List</fullName>
     <openType>onClickJavaScript</openType>
     <url>{!REQUIRESCRIPT(&quot;/soap/ajax/30.0/connection.js&quot;)}</url>
</webLinks>
...
</CustomObject>

Instead of embedding the code directly in the object, create a Visualforce button in a Visualforce Aura component, or use a Lightning Web Component.