Build Secure Apps with Lightning Web Components

Learning Objectives

After completing this unit, you’ll be able to:

Define Lightning Web Components (LWC).
Explain how LWC increases your application’s security.
Migrate from Visualforce or Aura to LWC.

Client-Side Security for Lightning Web Components

Lightning Web Components (LWC) is the Salesforce front-end JavaScript framework. Though Salesforce will continue to support Aura for the foreseeable future, LWC will eventually replace the Salesforce Aura Framework as the preferred user interface tool.

LWC contains many features from Aura, but its architecture is more akin to modern single-page application (SPA) frameworks, such as React or Vue. This means that while Aura and LWC serve the same purpose in the Salesforce developer ecosystem, LWC ships with modern security best practices inherited from SPA frameworks, like React and Vue. So when you build applications using LWC, you get up-to-date security built in by default.

Client-side security is increasingly important as developers continue to build applications on top of the Salesforce Platform with more and more user interaction. It’s imperative that, as a developer, you understand the built-in security mechanisms provided by LWC and know how to write secure client-side code on top of the LWC framework. Doing so helps you prevent security vulnerabilities in your applications and provide a much better user experience.

Security Features of Lightning Web Components

Salesforce recommends LWC as the primary UI development framework for use on the Salesforce Platform for two reasons.

Lightning Locker is the original architectural layer that enhances security by isolating individual Lightning component namespaces in their own containers and enforcing coding best practices. Lightning Web Security (LWS) is designed to make it easier for your components to use secure coding practices and aims to replace Lightning Locker. Lightning Locker has been the default security architecture for Lightning components. LWS started to replace Lightning Locker for Lightning Web Components initially in Spring ’22 and is now the default for new orgs. For more information, see the Lightning Web Security Basics module.

Also, LWC offers its own built-in security features, such as sanitization of malformed HTML code and blocking Content Security Policy (CSP) incompatible code.

LWC Security Best Practices

Load Assets Correctly

To import a third-party JavaScript or CSS library, use the platformResourceLoader module.

Download the JavaScript or CSS files from the third-party library’s site.
Upload the library to your Salesforce organization as a static resource, which is a Lightning security requirement.
In a component’s JavaScript file:

Import the static resource. import myResourceName from '@salesforce/resourceUrl/myResourceName';
Import methods from platformResourceLoader. import { loadStyle, loadScript } from 'lightning/platformResourceLoader';

The Lightning Platform resource loader guarantees your scripts always load in the correct order, are not duplicated, and load only when all dependencies have already loaded.

If you do not use the Lightning Platform resource loader, it’s possible that you or your customers may encounter page-breaking bugs as a result of a duplicated or improperly loaded script.

Properly Configure Event Propagation

After an event is fired, it can propagate up through the DOM. To understand where events can be handled, it’s helpful to understand how they propagate.

Lightning Web Component events propagate according to the same rules as DOM events. The default configuration is bubbles: false andcomposed: false. This configuration prevents the event from bubbling up through the DOM and from crossing the shadow boundary. The only way to listen to this event is to add an event listener directly on the component that dispatches the event. This recommended configuration is the most secure because it carries the least amount of risk.

The Principle of Least Privilege for LWC

The principle of least privilege is the idea that any user, program, or process has only the minimum privileges necessary to perform its function. Your components should have access only to the minimum required privileges and state required for proper functionality. This applies not only to the privileges and state of the client but also in any Apex controllers and in any third-party integrations.

Secure by Default

When designing an API, the secure option should always be the default option—even at the cost of rapid development. This means that future developers inherit the secure options built into the code.

Separation of Concerns

Rather than building monolithic components with many responsibilities, separate your concerns so that each LWC you build has one specific task. Imagine a monolithic LWC photoGallery that has commenting, layouts, and photo display functionality all in one. You can break down this component into more specific ones: photo, gridLayout, feedLayout, layoutManager, commentForm, commentList, commentContainer, and so on. Each iteration further increases the specificity of each component.

Properly Evaluate Third-Party Dependencies

Most JavaScript applications bring in a few third-party dependencies. It’s a good idea to evaluate third-party dependencies through manual review when possible. You can also use static analysis tooling, like Checkmarx, which makes it easy to scan code for security problems. Likewise, a tool like Snyk or OWASP Dependency-Check enables you to evaluate third-party dependencies against known vulnerability databases. Ensure that you plan for updating third-party dependencies, as many libraries and components release security updates regularly.

Migrating from Aura to LWC

Aura components and Lightning Web Components can exist in the same application. The programming model for Lightning Web Components is fundamentally different from the model for Aura components. Migrating a component is not a line-by-line conversion, and it’s a good opportunity to revisit your component’s design.

The easiest components to migrate are simple components that only render UI. You get more performance and developer productivity gains by migrating larger trees of components (components within components) rather than an individual component. However, it’s a useful learning experience to migrate one component and see how concepts in the Aura programming model map to concepts in the Lightning Web Components programming model.

After migrating one component, you are in a better position to determine whether it makes sense for you and your org to:

Undertake a larger migration effort.
Use Lightning web components for new components only.
Stick with Aura components for now.

The choice is specific to you and may depend on your use cases and available resources. Whatever decision you make, migrating a component is a valuable learning exercise.