Lightning Web Security vs Lightning Locker: what the Session Settings checkbox changes

In Setup, under Session Settings, there is a checkbox labelled "Use Lightning Web Security for Lightning web components and Aura components". Ticking it swaps the client-side security architecture your Lightning components run in, from Lightning Locker to Lightning Web Security (LWS). It is one of the bigger runtime changes an admin can make with a single click, and it is easy to misunderstand in both directions: some teams avoid it because they fear breakage, others assume it secures the whole component.

This post explains what LWS is, how it differs from Locker, how to turn it on, what to test first, and what it leaves to you.

#What Lightning Locker did

Lightning Locker was the original isolation layer for Aura and, later, Lightning Web Components. It wrapped the browser's global objects (window, document, DOM elements) in secure proxies, so a component in one namespace could not reach into the DOM or JavaScript of a component in another namespace. It also enforced strict mode and blocked a set of risky APIs.

The isolation worked, but the wrappers had costs. Code that expected the real window or document often behaved differently. Many third-party libraries needed patches or did not run at all. Components from different namespaces could not easily cooperate, even when the developer wanted them to.

#What Lightning Web Security changes

LWS keeps the same goal, namespace isolation, but gets there differently. Instead of wrapping globals in proxies, it runs each namespace's code in its own JavaScript sandbox and modifies the behaviour of specific risky APIs. Salesforce calls these modifications distortions. Code sees standard browser APIs, except where a distortion deliberately changes or blocks an operation.

In practice that means:

• Better library compatibility. Code that relies on standard globals tends to work without the workarounds Locker required.
• Cross-namespace composition. Components from different namespaces, including managed packages, can be composed and communicate in ways Locker blocked.
• Isolation still holds. One namespace's sandbox still cannot tamper with another's globals or reach code it should not.

LWS started with Lightning Web Components, and Aura support came later, which is why the checkbox now names both. On newer orgs it may already be on. Check rather than assume, because the setting is org-wide and the exact default depends on when the org was created and which release updates have been applied.

#How to turn on Lightning Web Security

1. In Setup, open Session Settings.
2. Find Use Lightning Web Security for Lightning web components and Aura components.
3. Select it and save.
4. Sign out and back in, or reload with a cleared browser cache, before you judge the result. Cached framework code can make the old behaviour linger.

Do this in a full or partial sandbox first. Because the setting applies across the org, it affects every Lightning page, Experience Cloud site and managed package component at once.

#What to test before enabling it

Most components work unchanged. The ones that break usually fall into a few groups:

• Components with Locker workarounds. Code written to detect or avoid Locker's secure wrappers can misbehave once they are gone. Search for references to Locker-specific objects and for comments explaining a workaround.
• Third-party libraries in static resources. Charting, PDF, mapping and editor libraries are the usual suspects. They often work better under LWS, but test every one you load with loadScript.
• Aura components. Aura picked up LWS later than LWC, and older Aura code has had the least exposure to it.
• Managed packages. Check each vendor's documentation for LWS support, and test the package's pages in your sandbox.
• Experience Cloud sites. Run through the public and authenticated pages, including any guest flows.
• Code that depends on blocked behaviour. A component that relied on Locker stopping something may now behave differently, which can be a functional change even when it is not a security one.

Use your browser's developer tools while testing: LWS reports a distorted or blocked operation as a console error, which tells you where to look.

#What Lightning Web Security does not protect

LWS is a client-side isolation layer. It protects one component's JavaScript from another's. It does not decide what data a user can read, and it cannot fix a component that is unsafe by design.

#Apex access

Every @AuraEnabled method is a server endpoint. Anyone with access to the Apex class can call it directly through the Aura endpoint, without loading your component at all. LWS has no part in that request. Access is decided by the class grant, the sharing keyword and the query mode, so an @AuraEnabled method in a without sharing class returns the same records whether Locker, LWS or neither is running.

#CRUD, FLS and sharing

Object, field and record access are enforced on the server: WITH USER_MODE, as user DML, Security.stripInaccessible and the Apex sharing keywords. LWS does not check any of them.

#XSS through unsafe DOM writes

LWS applies distortions that reduce what some injected markup can do, but Salesforce's guidance still treats unsafe DOM writes as the developer's problem. Writing caller-controlled input to innerHTML inside lwc:dom="manual", or rendering it with aura:unescapedHtml, remains a cross-site scripting risk. Let the template engine render values, and sanitize anything you must insert as HTML.

#Your own relaxations

Content Security Policy entries, trusted sites and iframes that allow arbitrary origins widen what a component can load or frame. LWS does not override a relaxation you configured.

The LWC security post walks through these failure modes with code.

#How a scanner helps

The parts LWS leaves to you are visible in source and metadata, which is where a static scan fits. Vulkro for Salesforce checks LWC and Aura bundles for:

• DOM XSS: lwc-dom-manual-bypasses-sandbox and LWC-WIRE-XSS-001 for innerHTML or insertAdjacentHTML writes inside lwc:dom="manual", and SF-AURA-CMP-003 for aura:unescapedHtml bound to user input.
• LWS policy relaxations: the SF-LWS-001 to SF-LWS-006 family reports unsafe-eval or unsafe-inline script policy, wildcard origins, wildcard frame sources, an explicit LWS opt-out on an exposed surface, and legacy Locker markers.
• postMessage listeners that act on event.data without checking event.origin (POSTMSG-001).
• On the server side, guest-granted @AuraEnabled methods with no authorization check (SF-GUEST-AURA-001).

vulkro-sf scan ./force-app

The check list is on the LWC and Aura detectors page.

#FAQ

#Is Lightning Web Security enabled by default?

On many newer orgs it is. Older orgs may still be on Locker. Check Setup, Session Settings, for "Use Lightning Web Security for Lightning web components and Aura components" rather than assuming.

#Can I turn Lightning Web Security off after enabling it?

Yes. It is a checkbox in Session Settings, so you can clear it to return to Lightning Locker. Test in a sandbox first so you rarely need to.

#Does Lightning Web Security prevent XSS?

It reduces the impact of some injected markup, but it does not make unsafe DOM writes safe. Avoid innerHTML with untrusted input and let the template engine escape values.

To check your components and Apex together, see Vulkro for Salesforce or start a 14-day trial from /start/.