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
- Interactions with global objects
elementglobal 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
iframecontent and identity
Your Lightning web components can access content in
iframeelements, 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
postMessageevent 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
elementobjects 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 Lightning Locker features with Lightning Web Security.
|Lightning Web Security
|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
|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.
|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.