How Lightning Web Security Compares to Lightning Locker
Lightning Web Security (LWS) and Lightning Locker both block or modify behavior of APIs that aren’t secure. In addition, as the newer architecture, LWS supports features that Lightning Locker doesn’t.
Here’s a summary of additional features that Lightning Web Security supports.
Your Lightning 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. See Components from Different Namespaces in the Lightning Web Components Developer Guide.
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.
Lightning components can access content in iframe elements if the iframe's src attribute isn't set or is set to about:blank. If src is set to a URL, LWS causes the browser to treat the iframe as cross-origin regardless of whether the source is same-origin or cross-origin. Browsers follow the same-origin policy to restrict cross-origin content. The iframe identity is maintained across the sandbox boundary, so you can check the identity of a postMessage event origin and use postMessage to communicate between the host page and the iframe. Lightning Locker blocks all access to content in iframes.
Your Lightning web components (LWC) can create custom elements and use third-party web components. Lightning Locker blocks the use of custom elements and third-party web components.
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. See Understand How LWS Architecture Affects Component Performance.
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.
Lightning Web Security is modeled after the latest TC39 standards that evolve with the browser platforms.
This table compares the features of Lightning Locker and 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. For LWC, Lightning Locker prevents you from breaking Shadow DOM encapsulation between components, and you can't modify shadowRoot properties. | LWC 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 can cause 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 isn't associated with any API version. When you enable Lightning Web Security, all Lightning components in the org are affected until you disable it. |
| Lightning Out (Beta) and Lightning Components for Visualforce (Beta) | To use Lightning Out, you must use Lightning Locker. See Lightning Out Requirements. | Lightning Out isn't supported when LWS is enabled. |
See Also