How Lightning Web Security Compares to Lightning Locker

Lightning Web Security blocks or modifies behavior of APIs that aren’t secure, as Lightning Locker does. In addition, the new architecture supports features that Lightning Locker doesn’t.

Here’s a summary of additional features that Lightning Web Security supports.

Cross-namespace component use: Your Lightning web components can import components or modules from other namespaces and use them via composition or extension. Components are isolated in their own namespace JavaScript sandbox, but it’s transparent to you because the security architecture performs virtual communication behind the scenes.
Interactions with global objects: Because each namespace is given its own detached JavaScript sandbox, we can expose window, document, and element global objects directly without needing to use wrappers to secure your components. Lightning Web Security modifies behaviors of those objects to prevent a component from accessing global objects used by components from another namespace.
Access to iframe content and identity: Your Lightning web components can access content in iframe elements, although web browsers prevent access to content from a different origin. The iframe identity is also maintained across the sandbox boundary, so that checking the identity of postMessage event origin works normally. Lightning Locker blocks access to content in iframes.
Use of custom elements and third-party non-Lightning web components: Your Lightning web components can create custom elements and use third-party web components. Lightning Locker blocks the use of custom elements and third-party web components.
Improved performance: Execution of your code in the JavaScript sandbox is faster than in Lightning Locker because Lightning Web Security doesn’t use secure wrappers, which can reduce performance.
Better support of third-party JavaScript: Libraries can use techniques such as manipulating global objects because they’re running in a JavaScript sandbox and their changes to globals don’t affect components in other namespaces. Lightning Locker provides secure wrapper versions of the window,document, and element objects to prevent access to some APIs of those global objects. The wrappers prevent use of some third-party libraries that access those protected APIs.
Compatibility with standard JavaScript as it evolves: Lightning Web Security is modeled after the latest TC39 standards that evolve with the browser platforms.

This table compares Lightning Locker features with Lightning Web Security.

Feature	Lightning Locker	Lightning Web Security
JavaScript strict mode	Enforced	Enforced
DOM access containment	Components can only access elements they create. See DOM Access Containment. Lightning Locker prevents you from breaking Shadow DOM encapsulation between Lightning web components. You can't modify `shadowRoot` properties.	Component access to the DOM is controlled by the browser through Shadow DOM, which is a web standard implemented in web browsers. Lightning Web Security enforces a closed `shadowRoot` by requiring `mode` to be `closed`, which provides additional encapsulation restrictions. See MDN Web Docs: ShadowRoot.mode.
Secure wrappers	Lightning Locker wraps JavaScript objects in more secure versions to prevent behavior that isn't secure. All interaction with the object is through the secure version of the object. See Secure Wrappers.	Lightning Web Security doesn't use wrappers. It uses distortions to selectively modify APIs that enable non-secure behaviors.
Custom elements allowed?	Lightning Locker blocks `customElements`. See Third-Party Web Components With Lightning Locker.	Lightning Web Security virtualizes `customElementRegistry` APIs to enable use of custom elements within your component namespace.
`eval()` function limitations	`eval()` is limited to the global scope by Lightning Locker. See eval() Function Is Limited by Lightning Locker	`eval()` isn’t blocked but is prevented from doing unsafe activities by distortions in the sandbox.
MIME types allowed in Blob objects	Lightning Locker allows a list of MIME Types Permitted.	The same MIME types are permitted. However, you must specify the MIME type when creating a Blob object.
Arrays passed to child components	Filtering arrays passed between components caused a performance problem in Lightning Locker. See Arrays Proxied When Passed to Child Components.	This issue is solved with Lightning Web Security because it doesn't filter DOM requests, and relies on shadow DOM.
Going back to previous version of Locker	Lightning Locker supports setting the org to use a previous version of Locker rules. See Select the Locker API Version for an Org.	The Locker API Version setting has no effect on Lightning Web Security. The setting to use Lightning Web Security is not associated with any API version. When you enable Lightning Web Security, all Lightning components in the org are affected until you disable it.