Get Started with Lightning Web Security
Learning Objectives
After completing this unit, you’ll be able to:
- Describe Lightning Web Security.
- List the benefits of Lightning Web Security.
What Is Lightning Web Security?
When admins and developers add new features and functionality to their orgs, org security is a top priority. Both prebuilt components (from Salesforce or the AppExchange) and custom-built components can introduce risks, allowing an org to be compromised by dangerous code.
But security shouldn’t come at the cost of performance or functional restrictions. So Salesforce created Lightning Web Security (LWS) to help you keep your org secure. LWS adds greater functionality through new Lightning component use cases. But before you learn more about LWS, let’s briefly look at its predecessor, Lightning Locker.
Note
As you work through this module, you may notice a difference in the way Lightning Web Components is capitalized. We capitalize all the words when we refer to the Lightning Web Components programming model. We only capitalize the first word when we refer to the components, themselves, as Lightning web components.
Lightning Locker
If you’re already using Lightning components, you’re familiar with Lightning Locker. Lightning Locker has been the standard for keeping your Lightning web components and Aura components secure by isolating Lightning component namespaces in their own containers and enforcing coding best practices. For example, a component named c-editor is from the c namespace, and is isolated from components in the ltngmu namespace.
Lightning Locker isn’t going away immediately. LWS for Lightning web components (GA) and LWS for Aura (beta) is enabled by default for orgs that don't contain custom Lightning web components or Aura components. This enablement continues the gradual rollout of the LWS architecture announced in Spring '22. Lightning Web Security is the future of component security and performance, so the sooner you can move to LWS, the safer and faster your org will be.
Note
This module covers Lightning Web Security. If you’d like to read more about Lightning Locker, see the link in the Resources section.
The Next Generation—Lightning Web Security
Lightning Web Security is the new kid in town for Lightning components. If you use Lightning components, you know that your Salesforce pages can contain components from any number of other companies. And your custom components commingle with components created by Salesforce and in apps on the AppExchange that you develop or use.
Having many components from different sources in your environment, including third-party libraries loaded from static resources, opens the door to potential threats. Malicious code in a component can access global objects like window, document, or element, obtain their resources or data, and wreak havoc across your org.
Security Through JavaScript Sandboxing
The architecture in Lightning Web Security works in your environment by isolating each component in a JavaScript sandbox dedicated to its namespace. Dangerous code from one component can’t access the resources of any other components outside of its namespace.
Lightning Web Security Use Cases
While both Lightning Locker and Lightning Web Security block or modify the behavior of APIs that aren’t secure, LWS offers these additional uses that enhance performance and security.
Cross-Namespace Component Use
Lightning web components can import components or modules from different namespaces and use them through composition or extension. Components are transparently isolated in their own namespace JavaScript sandbox. You won’t even know this is happening.
Interactions with Global Objects
Lightning Locker requires secure wrappers to isolate components, limiting performance and prohibiting the use of some third-party libraries. Lightning Web Security removes the need for secure wrappers by blocking or modifying the behavior of components where it detects unsafe code. It does this in the sandboxes where the code lives, so it can’t cause trouble. This allows you more freedom and flexibility to use third-party libraries in your components.
Access to iFrame Content and Identity
Lightning Web Security permits Lightning web components to access content in iframe elements, so you can use other web development features that were blocked by Lightning Locker.
Improved Performance
Without the need for secure wrappers, code in namespace JavaScript sandboxes executes faster.
Better Support of Third-Party JavaScript Libraries
In LWS, libraries can do things like manipulate global objects because they’re running in their own namespace JavaScript sandboxes. These changes to global objects won’t affect components in other namespaces.
Lightning Web Security Evolves as JavaScript Evolves
LWS is modeled after the latest TC39 standards that evolve with browser platforms, meaning it won’t go out of date as technology changes.
In the next unit, we dig deeper into how Lightning Web Security works, how you can tell if you have components that will be affected by LWS, and how to enable LWS in your org.