You are here:
CSP and Lightning Locker Design Considerations
Whether you’re an administrator, content manager, or developer, be aware of the impact of the different security levels on your Experience Builder site. This impact can be far-ranging and unexpected.
Required Editions
| Available in: Salesforce Classic and Lightning Experience |
| Available in: Essentials, Enterprise, Performance, Unlimited, and Developer Editions |
In addition to error messages and feedback, you can use the Developer Console to help identify any directive issues or CSP violations.
What Does the Strict CSP Level Affect?
Strict CSP is the default, maximum security level for Experience Builder sites. This level of security can impact many aspects of your site, especially resources that make calls to external sources, such as:
- Rich Content Editor
- HTML Editor
- Third-party components
- Custom components
headmarkup- CMS Connect content
In addition, Strict CSP mitigates the risk of cross-site scripting (XSS) and other content injection attacks by disallowing inline scripts.
unsafe-inline keyword.| Impact | Description | Example | Recommendation |
|---|---|---|---|
| Blocks inline scripts | All inline scripts, including inline <script> elements
and inline event handlers, are blocked from running on your site. Common services
such as Google Tag Manager can’t work properly when these scripts are blocked. |
You include an inline script in the head markup to write
messages to the console log for testing purposes, for example,
<script>console.log(“blocked”);</script>. Because all
inline scripts are blocked, messages aren’t written to the log. |
Replace inline scripts in your site and instead use a static resource that’s uploaded as a relative URL, or avoid inline scripts entirely. |
| Blocks remote JavaScript resources unless allowlisted | All requests for remote JavaScript files are blocked from executing, unless you explicitly allow those resources.. | You want to use the popular D3.js library to create a scatterplot. But because all remote JavaScript files are blocked, nothing is drawn. | Upload all JavaScript libraries to your org as static resources, and then add the static resource to your component. After the library is loaded from the static resource, you can use it as normal. Or you can host the asset as a static resource and refer to it with a relative URL |
| Blocks non-script remote resources unless allowlisted | All requests for non-script resources to external servers are prevented, unless you explicitly allow those servers. | You decide to host your company logo on an external server and reference it in a component. However, the image isn’t shown. | Host your resources through Salesforce using component functionality, such as the Rich Content Editor. Or you can host the asset as a static resource and refer to it with a relative URL. |
| Isolates third-party components and custom code when Lightning Locker is on | Third-party components and custom code from different namespaces are prevented from interacting and accessing each other’s DOM. These resources can only access supported APIs. If you inadvertently allow a malicious domain, isolated resources are unable to send data to that domain. |
By mistake, you use a malicious component on the same page that you’re exposing internal Salesforce records through a Salesforce out-of-the-box component. Because the components are isolated, the malicious component is unable to access those records. | Follow best practices for using third-party components in your site and custom
code in your If you have trouble getting third-party components or custom code to work with Lightning Locker, see Resolve Lightning Locker Conflicts in Experience Builder in the Experience Cloud Developer Guide. |
| Allows third-party components and custom code to communicate when Lightning Locker is off | Third-party components and custom code from different Third-party components and custom code from different namespaces can interact and access each other’s DOM. These resources can also use unpublished frameworks. And resources in an open browser tab are exposed, permitting third-party components and custom code to access and edit them. Partners and developers of managed packages on AppExchange must choose whether they want their components to be available when Lightning Locker is turned off. |
You want to use third-party components that automatically inject additional
third-party JavaScript into the page, including the site’shead
markup. |
Turning off Lightning Locker can potentially cause security flaws in your site and prevent third-party Aura components from being available at design time and rendering at runtime. Disable Lightning Locker only as a last resort. |
What Does the Relaxed CSP Level Affect?
To use resources from third parties such as Google, you can choose the Relaxed CSP level. But make sure that you understand the ramifications of a less secure, relaxed CSP environment on your site.
In this state, you can optionally disable Lightning Locker when custom functionality doesn’t work properly. But we strongly advise against turning off Lightning Locker. For information on Lightning Locker workarounds, see Resolve Lightning Locker Conflicts in Experience Builder in the Experience Cloud Developer Guide.
| Impact | Description | Example |
|---|---|---|
| Allows inline scripts | All inline scripts are allowed to run in your site, including scripts that use
eval(). These scripts are allowed because
many common services such as Google Tag Manager require them to work properly.
However, inline scripts are a common source of XSS attacks. |
You include in your head markup an inline
script to log every user action on a page for marketing-related analysis. Because
inline scripts are allowed, analytics are logged successfully. |
| Allows remote JavaScript and non-script resources when allowlisted | All requests to external servers for JavaScript files and non-script resources are allowed when you identify the servers. Client-side code can also make requests to your site. | You use a script that pulls in your company’s blog posts. For the content to show, allow the script for the site using the Trusted Sites for Scripts area in Experience Builder, and allow the non-script content host in Trusted URLs in Setup. |
| Isolates third-party components and custom code when Lightning Locker is on | Third-party components and custom code from different namespaces are prevented from interacting and accessing each other’s DOM. These resources can only access supported APIs. If you inadvertently allow a malicious domain, isolated resources are unable to send data to that domain. |
By mistake, you use a malicious component on the same page that you’re exposing internal Salesforce records through a Salesforce out-of-the-box component. Because the components are isolated, the malicious component is unable to access those records. |
| Allows third-party components and custom code to communicate when Lightning Locker is off | Third-party components and custom code from different namespaces can interact and access each other’s DOM. These resources can also use unpublished frameworks. And resources in an open browser tab are exposed, permitting third-party components and custom code to access and edit them. Partners and developers of managed packages on AppExchange must choose whether they want their components to be available when Lightning Locker is turned off in the relaxed CSP environment. |
You want to use third-party components that automatically inject additional
third-party JavaScript into the page, including the site’shead markup. |
See Also
- Experience Cloud Developer Guide: Using the Developer Console
- Lightning Web Components Dev Guide: Determine Whether a JavaScript Library Is Locker Compliant
- Lightning Aura Components Developer Guide: eval() Function is Limited by Lightning Locker
- Lightning Web Components Dev Guide: Use Third-Party JavaScript Libraries
- Lightning Aura Components Developer Guide: Using External JavaScript Libraries
- Experience Cloud Developer Guide: Enable Third-Party Components to Run When Lightning Locker Is Off
