You are here:
CSP and Lightning Locker in Experience Builder Sites
Experience Builder sites use Content Security Policy (CSP) and Lightning Locker to secure your site from malicious attacks and custom code vulnerabilities. CSP is a W3C standard that controls the source of content that can be loaded on your site’s pages and helps protect against cross-site scripting (XSS) attacks. Lightning Locker is a Salesforce architectural layer that allows third-party Lightning components and custom code to run safely on the same page in the browser. With different levels of security, you can optimize your site security choices and tolerance for risk.
Required Editions
| Available in: Salesforce Classic and Lightning Experience |
| Available in: Essentials, Enterprise, Performance, Unlimited, and Developer Editions |
For new sites created after the Spring ’19 release, Strict CSP is the default CSP setting.
What Is CSP?
CSP is a list of rules that define the Content-Security-Policy HTTP header that’s sent to the browser when someone visits your site. Web browsers use these rules to block requests to unknown servers for different kinds of resources such as scripts, images, and other data. Strict CSP makes your site the most secure against these kinds of attacks by preventing requests to other servers, unless explicitly allowed.
CSP determines what is part of your site and what isn’t. One of the most important aspects of CSP is how it defines the boundaries of your site. Anything not loaded through your site's domain name, such as a logo hosted on a separate company site, is considered a third-party host. This approach to CSP follows the same-origin policy that browsers already enforce. You can access third-party hosted materials, but you must choose a security level for your site first. Then, allow the hosts as appropriate.
What Is Lightning Locker?
Lightning Locker is a Salesforce architectural layer that enhances the security of the
third-party Lightning components in your site and custom code in your head markup. These third-party components and custom code can
contain security vulnerabilities that enable the exfiltration of data and potentially
malicious actions using that data.
Lightning Locker controls whether third-party components and custom code from different namespaces can share data or interfere with each other. If third-party components or custom code deals with sensitive data, communication between these resources is a special concern. For example, without Lightning Locker, a third-party component could include JavaScript that captures secure data that a customer enters in another component, and then send that data to their own servers. Lightning Locker ensures that third-party components and custom code that interacts with resources in other namespace can run safely even when together on the same page in the browser.
Lightning Locker:
- Uses containers to isolate all third-party components that belong to one namespace from third-party components in a different namespace.
- Enforces coding best practices by only allowing access to supported APIs and eliminating access to non-published frameworks.
- Turns on native security features in the browser.
By default, Lightning Locker is turned on for your site. Depending on your security level, you can choose to turn off Lightning Locker for all third-party components and custom code.
Security Levels
You can choose from these security levels.
| Security Level | Description |
|---|---|
| Strict CSP: Block Access to Inline Scripts and Permits Access to Allowed Hosts | Default setting for sites created in Spring ’19 (February 2019) and later. Provides maximum security.
|
| Relaxed CSP: Permit Access to Inline Scripts and Allowed Hosts | Provides moderate security.
|
| Allow Inline Scripts and Script Access to Any Third-party Host | Provides no added security, but enables your site to work as currently designed.
Note This option is only visible for sites created before Spring ’19. In
Spring ’22 (February 2022), this option is being removed. |
- 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. - Where to Allowlist Third-Party Hosts for Experience Builder Sites
Regardless of your security level, you must allowlist all non-script resources such as images, style sheets, and fonts that are hosted outside your Experience Builder site. And if you reference external JavaScript files in your site, you must allowlist these remote hosts. - Select a Security Level in Experience Builder Sites
Choose a security level to control whether scripts can be executed from your Experience Builder site and whether third-party components and custom code can share data.
