As the Lightning platform continues to evolve, empowering critical business processes and applications, one aspect takes center stage like never before: security. In a digital landscape teeming with threats, safeguarding both end users and a company’s invaluable data is becoming more important than ever.
Salesforce achieves this through the use of one of two security architectures, acting as a hidden guardian, ensuring a safe and secure environment. These two architectures are the new Lightning Web Security, which is intended to replace the older Lightning Locker.
How Do They Protect?
Regardless of whether you’re using Lightning Locker (Locker) or Lightning Web Security (LWS), both security architectures show their influence right at the beginning of any developer’s journey to create a custom Lightning component.
Both of them are client-side (meaning they run within an end user’s browser) security architectures designed to isolate components from different developers (e.g. Salesforce, AppExchange packages, and your own code). It is to prevent them from performing actions (potentially malicious) on components they aren’t supposed to (such as a managed package reading data from a local component) and to enforce safe and secure best practices.
While each architecture has the same aim, how they each achieve these goals under the hood is drastically different, leading to distinct advantages of the much more modern Lightning Web Security framework. Let’s take a dive into how they do this and explore how these differences can provide some advantages…
Locker Service
Locker Service takes a novel approach to achieve its security, which usually comes down to preventing API calls and forcing the use of Locker-compatible ones.
- DOM Access Containment: Locker prevents a component from reaching into elements it didn’t explicitly create. This is done by either blocking calls to APIs and forcing the use of non-standard ones (Aura is a great example of this) or by modifying their behavior behind the scenes to perform access checks. This leads to code that is either non-standard and so much more difficult to maintain or imparts a heavy performance penalty due to the access checks required.
- Secure Wrappers: Whenever a piece of data is accessed within a component running with Locker, that data is wrapped in a Secure Wrapper. This is a standard JavaScript Proxy object that intercepts any request to read and write to it and performs the access checks any time the data is accessed or written to. This imparts a performance penalty, and these proxies can be layered on top of each other when certain data types are passed to child components.
Lightning Web Security
LWS takes a radically different approach to Locker to achieve its security goals. Virtualization is the cornerstone of LWS, transforming how security is managed within the browser by acting as a virtualization engine.
It provides each namespace with its own sandboxed environment, which provides restricted and, more importantly, isolated access to its own resources within the browser. This follows a similar approach to hardware and operating system virtualization, such as with Docker, which securely powers an unimaginable amount of applications worldwide.
LWS doesn’t just provide a virtualized sandbox environment; it also uses the concept of distortions. These distortions effectively create a mutated version of a standard API within the sandbox, allowing a potentially insecure API to be changed to enforce a secure behavior.
LWS’s approach provides distinct differences compared to Locker, providing some distinct advantages that can make a stark difference to developer experience and, importantly, drastically reducing the limitations imposed on the Salesforce front end. These differences include:
- Cross-namespace components: Allowing modules or components from managed packages to be used by third parties – imagine being able to extend and customize an AppExchange app on a much greater scale.
- Use of global objects: Each namespace gets its own globals, e.g. window and document, allowing the use of standard APIs without running the risk of other components contaminating or modifying their behavior.
- Greater access to iframe content: Allowing a component to delve into an iframe (on the same origin), allowing safe and secure communication as expected.
- Third-party JavaScript support: As LWS sandboxes namespaces, mutates insecure APIs, and allows the use of global objects, third-party JavaScript libraries are far more likely to work as the APIs they are utilizing are much less likely to be blocked when compared to Locker. Now, those Google searches for node modules for use within your components will be much more fruitful!
- Compatibility with standard JavaScript: LWS is modeled after TC39 standards, meaning securely written modern JavaScript should just work.
Outside of the above, there is one distinct advantage to LWS over Locker: performance. As LWS does not rely on proxies, the performance penalty imparted by them and their access checks is not felt. Let’s take a look at a real-world scenario to show off the impacts of this – a parent component nesting a data table within it.
This parent component passes an array of SObjects to the table for display. In Locker, this array can get proxied several times. Due to the complexity of the array (as it is an array of objects), when the table tries to display the data, the proxies (which are now layered as multiple proxies) cause a potentially exponential decrease in performance. This decrease may even result in the browser becoming unresponsive (for several minutes, even on cutting-edge hardware) if there are more than a few rows in the table. As LWS does not utilize proxies, this limitation and performance hit are not felt, and the browser remains responsive.
Enabling Lightning Web Security
LWS sounds like a pretty major improvement over Locker, and the features it enables are getting better and better with every release. Turning it on seems like a pretty good idea, right? Like all major software transformations, there are some considerations that need to be taken into account before turning it on, some of which could be hard blockers. These are:
- Are there any custom components present in the org?
- Are there any Aura components present in the org?
- Are any third-party managed packages installed?
Depending on the answers to these questions, consider the following:
- There are no components present: Great news, feel free to turn it on in production; however, testing in a sandbox is always a good idea for new features!
- There are only LWCs present: Test it in a sandbox; however, it’s likely to work as expected or only require minor changes to components.
- There are Aura components present: Testing in a sandbox should be mandatory. LWS impacts Aura components far more than LWCs, so it’s best to test them before enabling it in production. You can also search your components for any of the known limitations listed here.
- You have managed packages installed: It’s crucial to perform tests within a sandbox to find any potential issues, which would be the same as the two bullets above. If you find an issue, reach out to the package developer and express that you have an interest in using their package with LWS enabled – if they don’t know there’s an issue, they can’t fix it!
So now you know your next steps and are ready to turn it on either within a sandbox or your production org (no skipping the testing step!).
- Go to Setup.
- Within the Quick Find, search for “Session Settings”.
- Go to the Session Settings page.
- Scroll down to the Lightning Web Security Header.
- Tick the Use Lightning Web Security for Lightning web components and Aura components checkbox.
Final Thoughts
Lightning Web Security offers some distinct advantages over the existing Lighting Locker paradigm we have been living with for many years. It provides much better performance, enables much more standardized code, and allows us to utilize much more amazing open-source JavaScript to take our Lightning components to the next level – all this while providing the end users with an ever-improving experience.
Although enabling LWS seems like a no-brainer, there are some key considerations that an org’s admin or developers must address to safeguard against any unintended effects of greater security and freedom. Once an org has been fully tested and LWS has been enabled, it can enjoy a bright future of lightning-fast performance and reap the seeds of standardizations.