Lightning Web Security FAQ

Frequently Asked Questions

Lightning Web Security Essentials

• What is Lightning Web Security?
• What problem does Lightning Web Security solve?
• How does Lightning Web Security work?
• How is Lightning Web Security different from Lightning Locker?
• Is Lightning Web Security more secure than Lightning Locker?
• Why should I move to LWS if Locker is just as secure?
• Should customers enable Lightning Web Security?
• What are the packaging implications for ISV partners?
• How does an ISV partner know if a customer is on LWS today?
• How does LWS affect Experience Cloud sites?
• Does Field Service use LWS?

LWS Enablement

• Will Salesforce turn on Lightning Web Security for customers?
• Is Salesforce automatically enabling LWS in Winter '25?
• What potential impact could there be when LWS is enabled by default in new orgs?
• Where is LWS enabled by default?
• Are some orgs that have enabled LWS excluded from using LWS for Aura components?
• How can I determine if my production org is using LWS for Aura components?
• If my org is excluded from LWS for Aura components, how can it be enabled?
• Can I disable Lightning Web Security after Salesforce enables it?
• After Lightning Web Security is enabled in my production org, is there a mechanism to specify exceptions at the component level?
• What is the timeline of the LWS rollout?

Learn More

• Where can I learn more about LWS?
• Where can I go if I have questions or concerns about LWS?

*********************************************************************************************************************************

Lightning Web Security Essentials

What is Lightning Web Security?
Lightning Web Security (LWS) is a new client-side security architecture for Lightning components that Salesforce first introduced in Spring ’22. This new architecture is defined by fewer restrictions and more functionality while providing strong sandboxing and a security posture to enforce namespace isolation. The result is strong, flexible, usable security for your Lightning components. New orgs have LWS enabled by default.

If you don’t enable LWS in your org, then Lightning Locker is enabled. Lightning Locker is the legacy security architecture for Lightning components. Instead of using virtual JavaScript sandboxes, Lightning Locker wraps JavaScript objects in more secure versions to prevent behavior that isn't secure. 

Back to Top

What problem does Lightning Web Security solve?
Lightning Web Security prevents Lightning components from interfering with or accessing data of components from other namespaces without the explicit permission of the namespace.

A Lightning page can include components created by multiple companies. Components created by an organization’s developer team coexist with components created by Salesforce. If you create and distribute apps in packages on AppExchange, your components coexist with components created by Salesforce and the components of the customer who installs your app.

Without preventative measures in place, a component can access the window global objects and obtain private resources or data from other components on the page. One measure is to isolate components by namespace so that a malicious component is unable to access the resources of components outside its namespace.

The namespace isolation is transparent and virtual, which enables components to appear to import components from other namespaces as if they’re all running in the same environment.

Back to Top 

How does Lightning Web Security work?
Lightning Web Security isolates components in a JavaScript sandbox dedicated to the components’ namespace. This sandboxing lets us expose document, window, and element global objects directly, without opening the door to security threats. LWS alters code running in the JavaScript sandbox to help prevent unsafe behavior. See How Lightning Web Security Works for more information.

Back to Top

How is Lightning Web Security different from Lightning Locker?
Lightning Web Security differs from Lightning Locker in the following ways:

• Cross-namespace component use. 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 LWS performs virtual communication behind the scenes.
• Secure interactions with global objects. Because each namespace is given its own JavaScript sandbox, we can expose document, window, and element global objects directly without needing to use wrappers to secure your components. Lightning Web Security modifies some 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 components can access content in iframe elements when the content is from the same 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. See Access to iframe Content in LWS.
• Use of custom elements and third-party non-Lightning web components. Your Lightning components can create custom elements and use third-party web components. Lightning Locker blocks the use of customer elements and third-party web components.
• Improved performance. Execution of your code in the namespace 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.
• 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 the 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.

Back to Top

Is Lightning Web Security more secure than Lightning Locker?
Lightning Web Security and Lightning Locker currently offer equivalent levels of security. The key difference is that Lightning Web Security allows increased JavaScript functionality and faster code execution.

LWS can securely enable features that Lightning Locker prevents because the architecture allows a more fine-grained approach to blocking unsafe behaviors. For example, instead of preventing use of an API entirely, LWS is able to prevent a component from setting a property of the API.

See How Lightning Web Security Compares to Lightning Locker for more information.

Back to Top

Why should I move to LWS if Locker is just as secure?
As Lightning Web Security integrates into the Lightning Experience platform, it provides the same security protections as Lightning Locker to ease the transition between the two architectures. We want your Lightning components to be able to run under either architecture initially. But the architectures are fundamentally different. 

LWS is adopting new web standards that are in active development, while Lightning Locker is a unique solution that Salesforce implemented when adequate web standards didn't exist yet. Think of LWS as the future of Lightning component security, and Lightning Locker as the legacy implementation of Lightning component security. Salesforce is a participant in the development of the web standards that LWS implements. Our development efforts are behind LWS now, and Lightning Locker is being maintained, not enhanced. 

You come out ahead by adopting LWS because it has better overall performance than Lightning Locker. The LWS architecture uses virtualization concepts in sandboxes instead of wrappers around every unsafe API. This approach reduces the performance penalty that's always imposed to ensure data security. After initial page load, components run faster under LWS than they do under Lightning Locker.

When all your components can run under LWS and you don't need to switch back to Lightning Locker, you can enhance your components to access other advantages described in How Lightning Web Security Compares to Lightning Locker.

The decision to move your org and components to LWS is a question of when to move, not if you should move. Eventually, Lightning Locker won’t be a viable solution for Lightning component security. The sooner you can move to LWS the better for your components’ security and performance.

Back to Top


Should customers enable Lightning Web Security?
Customers are strongly encouraged to enable LWS, first in a sandbox environment to test and then in production. LWS affects all Lightning components, including components installed through packages. For more information, see When to Enable Lightning Web Security. 


Back to Top

What are the packaging implications for ISV partners?
Packaging strategies for ISV partners depend on several factors, including the type of components used in the ISV solution, and the security architecture enabled in the customer org.

This table summarizes packaging implications for ISV partners.

*LWS-only features include global object manipulation, importing or extending components and modules from other namespaces, and accessing content in iframe elements.

For more information, see the What ISV Partners Need to Know About Lightning Web Security blog.

The partner can test their product in a sandbox or a test org on the latest release with LWS enabled to verify correct behavior. See Workflow to Try Your Components with Lightning Web Security.

After verifying that the product behaves as expected with Lightning Web Security, partners can work with their customers to determine if the customer org can enable Lightning Web Security. See When to Enable Lightning Web Security, which indicates the conditions where it’s OK to enable LWS in production.

If a partner is not taking advantage of new Lightning Web Security features, there is no need to maintain two versions of packages. A package that has worked with Lightning Locker will also work with LWS.

If a partner wants to release new packages to take advantage of features enabled by LWS, such as importing components from another namespace:

• Partner informs their customer that the customer org must enable Lightning Web Security to use the new packages.
• Customer consults When to Enable Lightning Web Security to verify that it’s supported to enable LWS in production in their org.
• Customer enables Lightning Web Security in their org and tests as described in Workflow to Try Your Components with Lightning Web Security to ensure their own components work as expected.
• After verifying components work as expected, the customer installs the partner packages and tests the product in their org.

If the partner also wants to support customers that can’t enable Lightning Web Security, the partner must provide separate packages that work with Lightning Locker until Salesforce has enabled Lightning Web Security 100% across all orgs.

Supporting customers on both architectures requires separate packages that are specific to Lightning Locker and Lightning Web Security only when the partner wants to use features that Lightning Locker blocks.

Back to Top

How does an ISV partner know if a customer is on LWS today?
Ask the customer to check the LWS setting in Setup, or programmatically check the value of the lockerServiceNext setting using the Metadata API. If the value is true, LWS is enabled. See the SessionSettings section of the Metadata API Developer Guide.

For Experience Builder sites, LWS and Locker are set independently of the org LWS setting. Ask the customer to check the setting for Lightning Locker in Experience Builder for Aura sites or Lightning Web Security for LWR sites. For more information, see Experience Cloud Developer Guide: Develop Secure Sites: CSP, LWS, and Lightning Locker and Experience Cloud Help: Select a Security Level in Experience Builder Sites.

The customer can also programmatically check the value of the isLockerServiceEnabled setting using the Metadata API. If the value is true, LWS is enabled in LWR sites. For Aura sites, when isLockerServiceEnabled is true, the site uses either Lightning Locker or LWS, depending how the hosting org is configured. See the ExperienceBundle section of the Metadata API Developer Guide.

Back to Top

How does LWS affect Experience Cloud sites?
Experience Cloud features multiple types of sites. See the Experience Cloud glossary for descriptions of each one.

Aura sites can include LWC components and Aura components. When the LWS setting is enabled in the org, LWS protects both types of components in Aura sites. When LWS is not enabled in the org, Lightning Locker protects the components in an Aura site. If you disable Lightning Locker in an Aura site’s settings, you disable the security architecture that’s currently in effect. If LWS is enabled at the org level, disabling Lightning Locker in the Aura site actually disables LWS for the Aura site.

LWR sites run using Lightning Web Runtime (LWR), which provides its own instance of LWS to protect the LWC components in the sites. Because there is a separate LWS instance, the org setting for LWS has no effect on LWR sites. If you disable Lightning Web Security in the LWR site, the site’s instance of LWS is disabled, even if LWS is enabled in the org. See LWR Template Limitations in Salesforce Help for additional information.

Salesforce Tabs + Visualforce sites aren’t protected by LWS or Lightning Locker. They use a different security architecture. The LWS setting in the org has no effect. However, if your Experience Cloud site uses Lightning Out (beta) to include Lightning components on a Visualforce page, then Lightning Locker is active on that page regardless of the org setting. 

For more information, see Develop Secure Sites: CSP, LWS, and Lightning Locker in the Experience Cloud Developer Guide.

Back to Top

Does Field Service use LWS?
Field Service uses Lightning Web Runtime, which provides its own instance of LWS. The LWS setting in the org doesn’t affect the instance used in Field Service. Custom Lightning web components that developers create to extend Field Service are protected by the LWS instance in LWR. Most of the LWS documentation is relevant to developers working with components for Field Service, except the information about enabling and disabling LWS in the org.

Back to Top
 

LWS Enablement

Will Salesforce turn on Lightning Web Security for customers?

Starting in Spring ’22, Salesforce began enabling LWS in some customer orgs. To minimize disruption for customers with highly customized environments, we’re postponing automatic enablement until further notice. If LWS isn’t enabled yet in your org, we encourage you to enable it in a sandbox environment to test your components running in LWS.

Back to Top

Is Salesforce automatically enabling LWS in Winter ’25?
In Winter ’25, we're not enabling any orgs for LWS. We’re postponing automatic enablement until further notice.

Back to Top


What potential impact could there be when LWS is enabled by default in new orgs?
We announced in the Winter ’23 release notes that LWS for Lightning web components is enabled by default in new Salesforce orgs. Starting in the Spring ’23 release, the LWS for Aura component (beta) was also enabled by default in new Salesforce orgs. LWS for Aura components became generally available in Summer ’23 and continues to be enabled by default in new orgs.

In customized orgs that you plan to merge or split into a new org, determine if Lightning components are used in the existing orgs. Similarly, if you are a multi-org customer, determine if Lightning components are used in any metadata templates and code repositories that you use to bootstrap new orgs. If you populate a new org with your own Lightning components or packaged Lightning components that you've been using in orgs without LWS enabled, be aware that they run with LWS enabled in the new org. Be sure to test your Lightning components or managed packages containing Lightning components in a sandbox environment with the setting Use Lightning Web Security for Lightning web components and Aura components enabled.

Ask managed package vendors if their packages are compatible with LWS. You can disable LWS if necessary, but we recommend that you open a support case to help resolve any issues with LWS first.

Back to Top

Where is LWS enabled by default?
LWS now affects Lightning web components and Aura components, and is enabled in these types of orgs:

• New orgs
• Scratch orgs
• Production orgs that don't contain LWC or Aura components
• Production orgs that contain LWC components, but don't contain Aura components, if LWS for LWC was enabled in Spring ’23

Back to Top

Are some orgs that have enabled LWS excluded from using LWS for Aura components?
Yes. An internal setting excluded LWS for Aura for production orgs that contained Aura components to prevent them from unknowingly participating in the LWS for Aura beta program. This setting remains in effect in those orgs. 

Test your Aura components with LWS enabled in a sandbox org before requesting Salesforce to turn off the LWS for Aura exclusion setting. 

Back to Top

How can I determine if my production org is using LWS for Aura components?
See Determine if Lightning Web Security Affects Your Org and Enable LWS in an Org in the Security for Lightning Components developer guide.

Back to Top

If my org is excluded from LWS for Aura components, how can it be enabled?
If you determine that your production org is excluded from LWS for Aura, contact Support to request removal of the LWS for Aura exclusion. We strongly recommend that you first test your Aura components in a sandbox org with LWS enabled. To allow for testing, LWS for Aura is not excluded in a sandbox org if it is excluded in a production org.

Back to Top
Can I disable Lightning Web Security after Salesforce enables it?
Yes. You can easily return to using Lightning Locker for Lightning components by deselecting Use Lightning Web Security for Lightning web components and Aura components on the Session Settings page.

Back to Top

After Lightning Web Security is enabled in my production org, is there a mechanism to specify exceptions at the component level?
No. When Lightning Web Security is enabled, all Lightning components in the org are affected. LWS can’t be disabled on individual components and is not associated with an API version.

Ensure that all your Lightning components are ready to run in LWS before enabling it in a production org. See Workflow to Try Your Components with Lightning Web Security for more information.

Back to Top

What is the timeline of the LWS rollout?
The goal of our gradual LWS rollout was to start with orgs that are not expected to be affected by LWS and to eventually enable LWS for all orgs. However, in Summer ’24, to minimize disruption for customers with highly customized environments, we decided to indefinitely postpone automatic enablement.

 If Salesforce resumes enabling LWS in the future, we’ll announce it in the release notes. If LWS isn’t enabled yet in your org, we encourage you to enable it in a sandbox environment to test your components running in LWS.

Here’s a summary of the rollout status by release.

Spring ’22

• Lightning Web Security became generally available for Lightning web components, but not for Aura components. See the Spring ’22 release note Secure Your Components Better, Stronger, Faster with Lightning Web Security.
• Salesforce gradually enabled Lightning Web Security for Lightning web components for thousands of customers whose orgs contained only Lightning web components, after advance notification through email.

Summer ’22

• Improvements to the debugging experience when LWS is enabled. See the Summer ’22 release note Debug Your Code More Easily to Run with Lightning Web Security.
• No customer orgs were enabled.

Winter ’23

• LWS for Lightning web components is enabled by default in new orgs and scratch orgs. See the Winter ’23 release note Use Lightning Web Security by Default in New Salesforce Orgs.
• Select customers participated in a closed pilot program for LWS for Aura components.
• No customer orgs were enabled.

Spring ’23

• LWS for Aura components became available as a beta feature, controlled through the same Setup setting. See the Spring ’23 release note Use Lightning Web Security for Lightning Web Components (GA) and Aura Components (Beta).
• The setting name changed to Use Lightning Web Security for Lightning web components (GA) and Aura components (Beta). 
• Use Lightning Web Security for Lightning web components (GA) and Aura components (Beta) was enabled in orgs with no custom components. See the Spring ’23 release note Lightning Web Security Enablement for Orgs with No Custom Components.
• Use Lightning Web Security for Lightning web components (GA) and Aura components (Beta) was enabled in production orgs that had LWS for LWC enabled in their org before Spring ’23, if the orgs had no Aura components. An internal setting excluded LWS for Aura for production orgs that contained Aura components to prevent them from unknowingly participating in the LWS for Aura beta program. However, the sandbox orgs associated with those production orgs weren’t excluded from LWS for Aura beta.

Summer ’23

• LWS for Aura components is generally available, and is controlled through the same Setup setting. See the Summer ’23 release note Use Lightning Web Security for Lightning Web Components and Aura Components (Generally Available).
• The setting name changed to Use Lightning Web Security for Lightning web components and Aura components. 
• The internal setting that disabled LWS for Aura in production orgs that contain Aura components in Spring ’23 is still in effect for those orgs in Summer ’23. Sandbox orgs associated with those production orgs weren’t excluded from LWS for Aura.

Winter ’24

• Salesforce is continuing LWS enablement in a large set of customer orgs. The transition from Lightning Locker is expected to be smooth for these orgs. 
• The internal setting that disabled LWS for Aura in production orgs that contain Aura components in Spring ’23 is still in effect for those orgs in Summer ’23. Sandbox orgs associated with those production orgs aren’t excluded from LWS for Aura. 

Spring ’24

• Salesforce is not enabling LWS in any customer orgs in this release. 
• The internal setting that disabled LWS for Aura in production orgs that contain Aura components in Spring ’23 is still in effect for those orgs in Spring ’24. Sandbox orgs associated with those production orgs aren’t excluded from LWS for Aura.

Summer ’24

• Salesforce is postponing enablement of LWS in customer orgs until further notice.
• The internal setting that disabled LWS for Aura in production orgs that contain Aura components in Spring ’23 is still in effect for those orgs in Summer ’24. Sandbox orgs associated with those production orgs aren’t excluded from LWS for Aura.

Winter ’25

• Salesforce is postponing enablement of LWS in customer orgs until further notice. 
• The internal setting that disabled LWS for Aura in production orgs that contain Aura components in Spring ’23 is still in effect for those orgs in Winter ’25. Sandbox orgs associated with those production orgs aren’t excluded from LWS for Aura. 

Back to Top

Learn More

Where can I learn more about LWS?
Customers and partners can use the following resources to learn more about LWS:

• Security for Lightning Components developer guide:

  • Lightning Web Security

  • How Lightning Web Security Works

  • How Lightning Web Security Compares to Lightning Locker

  • When to Enable Lightning Web Security

• Release Notes:

  • Lightning Web Security Enablement Rollout Remains Postponed (Winter ’25)

  • Gain Insight into Component Code by Switching LWS Distortions Off and On (Winter ’25)

  • API Distortion Changes in Lightning Web Security (Winter ’25)

  Blog:

  • • What ISV Partners Need to Know About Lightning Web Security

• Partner Learning Camp:

  • Lightning Web Security Implementation Basics

Back to Top
 
Where can I go if I have questions or concerns about LWS?

• To get help or report an issue, open a Support case with topic = Developer Support to determine whether there is a bug in your code or in the framework.

• Log an Idea if your use case is not currently supported.

• To ask questions, visit our Lightning Components Development Group on Trailblazer Community.

Back to Top