Experience Cloud Developer Guide

Get Up to Speed with Experience Builder Sites
Develop Experience Builder Sites: The Basics
Brand Your Aura Site
Develop Secure Sites: Authenticated and Guest Users
Develop Secure Sites: CSP, LWS, and Lightning Locker
Resolve Lightning Locker Conflicts in Aura Sites
Enable Third-Party Components to Run When Lightning Locker Is Off
Example: Adobe Analytics and Lightning Locker in Aura Sites
Add Pardot Tracking to Your Experience Builder Site
Use a CMS with Your Experience Builder Site
Report on Deflections: The Deflection Signals Framework
Avoid Deployment Issues When Moving to Enhanced LWR Sites
Considerations for Deploying Authenticated LWR Sites
ExperienceBundle for Experience Builder Sites
PDF

Develop Secure Sites: CSP, LWS, and Lightning Locker

Aura and LWR sites in Experience Cloud use Content Security Policy (CSP) and either Lightning Web Security (LWS) or Lightning Locker to secure the site from malicious attacks and custom code vulnerabilities. Factor in the potential impact of these security features when you develop your own custom components, use third-party components, or add custom code in the head markup.

CSP

CSP is a W3C standard for controlling the source of content that can be loaded on a page. CSP rules work at the page level and apply to all third-party components and custom code. By default, the framework’s headers allow content to be loaded only from secure (HTTPS) URLs and forbid XHR requests from JavaScript.

Different levels of CSP script security are available from Experience Builder. CSP levels are specific to each site.

Lightning Locker and Lightning Web Security

The Lightning Locker architectural layer enhances security by isolating individual Lightning component namespaces in their own containers and enforcing coding best practices. Lightning Locker has been the default security architecture for Lightning components and for Aura sites in Experience Cloud.

LWS is designed to make it easier for your components to use secure coding practices and aims to replace Lightning Locker. As with Lightning Locker, the goal of LWS is to prevent Lightning components from interfering with or accessing data that belongs to platform code or components from other namespaces. However, the architecture of Lightning Web Security protects Lightning web components using a different approach.

How LWS Applies At the Org and Site Levels

An admin can enable LWS at the org level to be used throughout the org instead of Lightning Locker via the Use Lightning Web Security for Lightning web components and Aura components setting in Session Settings in Setup.

This org-level setting affects Aura sites because when LWS is enabled in the org, LWS replaces Lightning Locker at the site level. Then, if you disable the Lightning Locker setting in Experience Builder for an Aura site, you’re actually disabling LWS.

LWR sites have their own instance of LWS, so the org setting for LWS has no effect on LWR sites. If you disable Lightning Locker in the LWR site, the site’s instance of LWS is disabled, even if LWS is enabled in the org.

By default, Strict CSP is enabled for all new Experience Builder sites, which means that Lightning Locker or LWS is also enabled. To access the Lightning Locker setting in Experience Builder, select Relaxed CSP.

For the B2B store and the D2C store LWR templates in Commerce Cloud, LWS isn’t enabled by default and can't be enabled.

Note

This table summarizes the effect of the org-level setting and the site-level setting in an Aura or LWR site.

Experience Cloud site framework Site-level setting Org-level setting LWS or Locker used in the site
Aura On On On
On Check On
Check On Lightning Locker
Check Check LWS
LWR On On On
On Check On
Check On LWS (site’s instance)
Check Check LWS (site’s instance)