Lightning Web Security (LWS) is the security model that sandboxes Lightning Web Components in production orgs. It replaces Locker Service for LWC. Locker is still around — Aura components still run in it — but every LWC interview today should touch on the LWS distinction.
What both models try to do
Both Locker and LWS exist for the same reason: multi-tenancy plus third-party AppExchange code. Salesforce orgs run components from multiple namespaces side by side — your custom code, managed packages, ISV apps — and the platform can’t let one namespace read another’s DOM, fetch its private data, or hijack its globals. Both models enforce that boundary.
Locker Service — the older model
Locker (introduced 2016 for Aura, extended to LWC) wraps every global the component touches — window, document, Element, XMLHttpRequest — in a secure facade. The facades:
- Strip out properties and methods Salesforce considered unsafe.
- Filter DOM access so a component can only see its own DOM subtree.
- Block direct access to other namespaces’ components.
The problem: Locker was implemented by monkey-patching the global object. Third-party libraries that did capability detection (e.g. if (window.fetch)) would see warped facades and break in subtle ways. The list of incompatible JS libraries was long.
Lightning Web Security — the newer model
LWS, generally available since Summer ‘21 (off by default; opt-in via Session Settings), takes a different approach: each namespace gets its own JavaScript Realm via the SES-Shim (Secure ECMAScript). Within its realm a component sees a near-vanilla browser environment; cross-realm communication is mediated through a thin bridge.
| Locker Service | Lightning Web Security | |
|---|---|---|
| Frameworks | Aura + (legacy) LWC | LWC only |
| Implementation | Monkey-patched DOM facades | Per-namespace JavaScript Realms |
| Third-party JS compatibility | Limited | Much broader |
| Cross-namespace DOM access | Blocked via facade | Blocked via realm isolation |
| Enable mechanism | Always on | Opt-in via Session Settings (one toggle per org) |
| Modern browser features available | Subset | Full standard set |
| Performance overhead | Per-call wrapping | One-time realm setup |
The practical impact on you as a developer
Third-party libraries that didn’t work under Locker often work under LWS. Charting libraries, date pickers, drag-and-drop helpers — anything that did typeof window.foo and got back a warped object now sees a real one. Salesforce maintains a compatibility list, but the practical experience is night and day.
You can no longer reach into another namespace’s DOM. Under Locker you couldn’t either, but the failure mode was different. With LWS, attempts to traverse to another component’s shadow root return null cleanly.
Some Locker workarounds become unnecessary. Patterns like importing @salesforce/resourceUrl/jquery to get a Locker-blessed jQuery build are obsolete under LWS.
Enabling LWS
LWS is not enabled by default in most orgs — it’s an org-wide toggle in Setup → Security → Session Settings → Use Lightning Web Security for Lightning web components and Aura components. Once enabled:
- All LWC code runs in LWS.
- All Aura code can also run in LWS via the same toggle (newer Aura support).
- The change applies immediately to all components.
Most orgs running newer code can flip it on. Older orgs running heavy Aura estates sometimes leave it off pending compatibility testing.
How to verify you’re under LWS
Inside a component, check:
console.log(navigator.userAgent);
// LWS realms expose a near-real user agent; Locker often masked it.
console.log(typeof window.fetch);
// 'function' under LWS, often 'undefined' or a facade under Locker.The official way is to check the org session setting, not runtime sniffing — but the runtime checks are useful for migration debugging.
Where Locker still lives
- Aura components in orgs where the LWS-for-Aura toggle is off.
- Older Lightning communities running Aura-based templates.
- Some sandbox orgs that haven’t been refreshed since the LWS GA.
If you’re maintaining an Aura estate, you’re probably still on Locker for the Aura side even if your new LWC code uses LWS.
Common interview follow-ups
- “Why did Salesforce build LWS instead of fixing Locker?” — fundamentally different architecture. SES Realms are a TC39 proposal-grade isolation primitive; Locker was a 2016-era polyfill of similar ideas. The cost of retro-fitting Locker to use Realms was higher than building LWS clean.
- “What happens when an LWC and an Aura component talk to each other across the LWS/Locker boundary?” — Salesforce mediates the bridge. Events, properties, and slot content cross via a sanitisation layer. Most code “just works” but complex object payloads can lose structure.
- “Is LWS a hard sandbox?” — close to one. It’s not the same as cross-origin isolation (you can’t break the realm by escaping a
Functionconstructor like you could with weaker sandboxes), but it’s not the OS-level isolation of a different process either. For practical purposes, treat it as strong enough to block accidental cross-namespace leakage and most malicious patterns.
Interview-worthy summary
If asked in one breath: “LWS is the modern per-namespace JavaScript Realm sandbox that replaced Locker Service for LWC. It supports more third-party libraries, uses real DOM objects instead of facades, and is enabled org-wide via a single Session Settings toggle. Aura still uses Locker unless the org has flipped the LWS-for-Aura switch on.”
Verified against: LWC Developer Guide — Lightning Web Security, Salesforce Help — Enable Lightning Web Security. Last reviewed 2026-05-17 for Spring ‘26 release.