Build Components to Work with Lightning Web Security

When you develop Lightning components that are compatible with Lightning Web Security (LWS), follow these coding guidelines.

Avoid Mutating Objects: When you mutate an object in a component that’s running in LWS, that change isn’t propagated outside the namespace sandbox. Consider mutation alternatives, such as creating a shallow clone.
Avoid Using Map Objects: Use of the Map object with LWS enabled can run into issues when the object is serialized. Instead of using a Map instance, you can use a plain JavaScript object in most cases.
Avoid Custom Properties on Standard JavaScript Objects: Adding custom properties directly to a standard built-in JavaScript object can cause issues when the object is serialized. If you must add custom data to a DOM element, use the dataset property of DOM elements instead.
Specify a MIME Type for Blob Objects: LWS requires you to set the MIME type when you create Blob objects. LWS permits some MIME types, sanitizes some MIME types, and blocks the rest.
Script Tags Transformed to Fetch Calls: LWS transforms <script> tags into fetch calls. LWS downloads the script to evaluate it in the sandbox.
Access to iframe Content in LWS: Lightning components can access content in iframe elements if the iframe's src attribute isn't set or is set to about:blank. If you set the src 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.
URL Protocol Schemes Allowed: LWS restricts the HTMLObjectElement.data attribute and the src attribute for iframe elements to values that use the http:// and https:// schemes. URL schemes such as javascript:// aren't allowed.
Aura Endpoints Disallowed by LWS: LWS blocks access to URL endpoints containing /aura and /webruntime because they’re part of the Lightning Component framework.
Analytics Libraries Blocked by LWS: LWS prevents the third-party analytics scripts from accessing code running in the browser outside the JavaScript sandboxes.
Salesforce Global Variables Blocked by LWS: For Lightning web components, LWS blocks access to some global JavaScript objects that are available to other Salesforce features, such as $A, Aura, Sfdc, and sforce.
Third-Party Library Considerations for LWS: Third-party scripts can encounter issues when running with LWS enabled if they have certain behaviors, such as adding themselves to the global window object or explicitly setting "use strict".
Local Storage Limitations: LWS creates synthetic storage for each sandbox. The synthetic storage prevents code in one sandbox from retrieving data that belongs to another namespace or that was set in the global scope outside LWS sandboxes, which impacts the usage of the localStorage and sessionStorage APIs.
Objects Passed Between Components Are Proxied: To maintain namespace isolation and reduce incompatibility, LWS proxies objects that are passed between components. To avoid issues related to proxies, pass values as JSON strings and parse them later.
Understand How LWS Architecture Affects Component Performance: LWS uses proxy objects, which can have a performance cost. To optimize performance, reduce heavy DOM usage where possible. When creating large collections of objects, minimize the use of global objects and use plain JavaScript objects instead.