How Lightning Web Security Works in Salesforce

In this post, I’ll be talking about how Lightning Web Security can make developers’ lives easier on the Salesforce Platform when building Lightning Web Components and how it replaces the Lightning Locker Service.

This 2023 one of my goals is to get the Salesforce Javascript Developer certification. With my shift to a solution architect role with my client project I haven’t been touching Javascript for some time and being a developer has always been close to my heart. My approach to upskilling is I decided to write several blog posts as I learn. I’ll start and cover the basics concepts.

What is Lightning Locker Service?

Lightning Locker is the default security architecture for Lightning components (Aura/LWC). It primarily isolates components in one namespace from interacting with other components from a different namespace and promotes best practices when coding.

How is this implemented?

  • Javascript Strict Mode – in strict mode, libraries that your component uses must also work in strict mode, with strict mode;
    • you need to attach variables to the window object to make them global
    • variables should be defined before assigning a value (best practice)

[gist]0620254a959a5fc9d1bf4fdf9d6bd4fe[/gist]

  • DOM access containment – you cannot traverse a DOM from a different namespace to prevent anti-pattern
  • Secure wrappers – restricted use of global objects instead Locker Service uses wrappers for example – window to SecureWindow
    • window
    • document
    • element
  • eval functionality is limited in scope
    • eval() function is supported to enable use of third-party libraries
    • can’t access local variables within the scope in which it’s called
  • MIME Types permitted
    • Locker permits some MIME types, sanitizes some and blocks the rest
  • Access to supported Javascript API Frameworks methods only

Why is Locker Service challenging?

Locker Service posts some challenges from using popular Javascript third-party libraries which may need access to the global objects and when imported to Salesforce may not work(risks of XSS attacks).

What is Lightning Web Security?

Lightning Web Security(LWS) is a new security architecture that will be replacing the Lighting Locker eventually but for now, it is only applicable for LWC initially. It is based on the concept of component virtualization but through a browser in an isolated environment called Javascript sandboxes. The new technology addresses the following.

  • it is based on modeled on the TC39 standards
  • Opens up access to the Javascript global objects, not through wrappers like what Locker Service does but instead uses distortions.
    • above access should mean better support for third-party Javascript libraries
  • and noticeable improvements as there is no need for wrappers
  • eval() is no longer blocked but still prevented from running malicious code.
  • components access to the DOM is controlled by the browser via the Shadow DOM. Locker service only allowed access to elements they create.
  • No longer filter DOM requests, unlike in Locker Service where arrays passed between components cause performance problems because of filtering.

How to Enable LWS?

Test it out first in a sandbox and test if your components are working well. Ideally no refactor is needed.

  1. From Setup, in the Quick Find box, enter Session, and then select Session Settings.
  2. On the Session Settings page, select Use Lightning Web Security for Lightning web components and save.
  3. Clear your browser cache after enabling or disabling Lightning Web Security to ensure the correct files are loaded in the browser. If you suspect that the correct security architecture is not in effect, see Delayed Enabling or Disabling of LWS.

Summary

This looks like a very promising change and moves the Lightning Web Components to the web standards without relying on Proxy for security. Javascript sandbox virtualization for components is something I would be keeping an eye on as things progress. But for now, we can explore more Javascript third-party libraries and extend our components further with fewer risks of XSS attacks.

Stay tuned for more posts around this topic.

Leave a Reply

Your email address will not be published. Required fields are marked *