The Power of Lightning Web Security
by Martina Dimitrievska, Salesforce Developer at codeSTREETS
When constructing a Lightning component, incorporating security measures is essential. Lightning Web Security (LWS) is crucial in this context, offering a robust framework to safeguard against cross-component data interference. This blog provides an overview of LWS, detailing its functionalities in maintaining component isolation, contrasting it with Lightning Locker, and outlining the steps to enable it.
The importance of LWS
To illustrate the importance of security in Salesforce development, consider a scenario where a Salesforce page hosts a variety of components from different sources: proprietary components developed by your organization, standard components from Salesforce, and third-party components installed via the AppExchange. Without security measures, there is a risk that these components could inadvertently or maliciously access each other's data, posing a significant security threat.
Lightning Web Security (LWS) addresses the security threat by implementing a virtualization technique. It creates individual JavaScript sandboxes for each namespace, effectively isolating the components and preventing unauthorized data access.
LWS in Action: Browser Virtualization
Lightning Web Security (LWS), at its core, utilizes the principle of virtualization to transform the browser into a controlled host environment. In this role, LWS functions as the virtualization engine, responsible for managing and regulating the virtual environments, specifically the namespace sandboxes. Within these sandboxes, each component is granted restricted access to specific resources, including global objects, network access, cookies, and other relevant elements. This approach ensures a secure and controlled interaction of components within the Salesforce ecosystem.
LWS in Action: Distortion
LWS includes a technique called distortion, which dynamically modifies native JavaScript APIs to prevent unsafe behavior. A distortion achieves the following:
-
Prevents API attempts to alter content and data outside the JavaScript sandbox.
-
Restrains running code within the boundaries of the sandbox.
-
Limits access inside the JavaScript sandbox to DOM and shared global objects, such as window.location and cookies.
Common API distortions in LWS include:
-
Content filtering: Filters out attempts to access properties in other sandboxes, for example in document.cookie, localStorage, sessionStorage, but allows them in the current sandbox.
-
Sanitization: Strips out malicious code, especially from innerHTML and outerHTML elements.
-
Property accessor modification: Prevents reading or writing values of specific properties, like shadowRoot.mode.
LWS vs. Lightning Locker
Mentioning Lightning Locker is relevant as it is also a security architecture for Lightning components. It should be noted that both LWS and Lightning Locker provide comparable levels of security. The primary difference lies in functionality and performance. With its fine-grained approach to blocking unsafe behaviors, LWS allows for increased JavaScript functionality and faster code execution.
The essential distinction between Lightning Web Security (LWS) and Lightning Locker lies in their respective approaches to evolving web standards and future development. LWS is designed to actively embrace new web standards, establishing itself as the forward-looking solution for Lightning component security. While Lightning Locker continues to be maintained, LWS stands out as the more advanced option, optimized for performance and functionality. This focus on future readiness and adaptability underscores several key reasons for preferring and ensuring the implementation of LWS over Lightning Locker
Cross-namespace component use. LWS allows Lightning components to import components or modules from other namespaces, ensuring isolation in JavaScript sandboxes with transparent virtual communication.
Secure interactions with global objects. LWS directly exposes document, window, and element global objects to each namespace's JavaScript sandbox, eliminating the need for wrappers to secure components.
Access to iframe content and identity. LWS permits Lightning components to access content in iframe elements, even from different origins, while maintaining iframe identity across sandbox boundaries, unlike Lightning Locker.
Use of custom elements and third-party non-Lightning web components. LWS supports creating custom elements and using third-party web components, unlike Lightning Locker, which restricts such usage.
Improved performance. Execution of code in the namespace JavaScript sandbox is faster with LWS than Lightning Locker, thanks to the absence of secure wrappers.
Better support for third-party JavaScript. LWS allows libraries to manipulate global objects without affecting components in other namespaces, while Lightning Locker's secure wrappers can limit access to protected APIs, hindering some third-party libraries.
Compatibility with evolving JavaScript standards. LWS aligns with the latest TC39 standards, evolving with browser platforms for enhanced compatibility.
Enabling LWS [in your Org]
To fully experience and harness the capabilities of Lightning Web Security (LWS) in your organization, follow these steps:
-
1. From Setup, enter "Session" in the Quick Find box.
-
2. Select "Session Settings."
-
3. On the Session Settings page, choose "Use Lightning Web Security for Lightning web components and Aura components" and save your changes.
-
4. Clear Browser Cache. Ensures that the correct files are loaded and the security architecture takes effect as intended.
Conclusion
Transitioning to LWS is to be seen as “just a matter of when.”
Adopting LWS is crucial for ensuring enhanced security and performance of your components within the dynamic Salesforce environment. The sooner organizations make the shift, the more advantageously they position themselves for the cutting-edge developments in Lightning component technology.
Embracing LWS is not merely about keeping pace; it's about leading the charge in the evolving landscape of Salesforce development.
About codeSTREETS
codeSTREETS is a Registered Partner of Salesforce, with the HQ in Amsterdam, The Netherlands, and the Salesforce Center of Enablement in Skopje, North Macedonia.
If you want more information on how codeSTREETS can support your Salesforce Automation needs, contact us at contact@codeSTREETS.com.
Alternatively, you can read more about the Salesforce Services codeSTREETS delivers on our site.