Explore Developer Tools for Lightning Web Security

Learning Objectives

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

• Determine if you have components in your org that are affected by Lightning Web Security.
• Describe the tools available to help you implement Lightning Web Security.
• Explain how Lightning Web Security tools work to keep your org secure.

Which Components Does Lightning Web Security Impact?

Lightning Web Security 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 Lightning Web Security. Lightning Web Security affects custom components created in your org and custom components installed in your org through packages.

If you’re not sure which types of components you have in your org, you can look in Setup to find out. In Setup, type Lightning Components in the Quick Find and select Lightning Components.

You’ll see a list of Lightning components that are installed in your org.

• The Type column tells you whether a component is an Aura component or a Lightning web component. You can sort the list to group the LWCs.
• The  icon tells you that a component is from a managed package.

Ensure the Compatibility of Your Components

We've already mentioned that LWS for Lightning web components and Aura components is now enabled by default in new Salesforce orgs. When it's enabled, LWS only affects custom Lightning components that you create in your org or install through managed packages.

If your org wasn't enabled by Salesforce in Spring '22, you can still take advantage of Lightning Web Security for your Lightning components by enabling it manually. Before manually enabling, though, make sure that your Lightning components will work with LWS.

Important!  LWS affects all Lightning components in your org, and it can’t be turned off for individual components once it’s enabled.

If you have Lightning web components for which you want to take advantage of the additional functionality offered by LWS, like importing a module from another namespace, you can refactor the code to make it work.

Note

When refactoring, keep in mind that once you refactor your code, it will no longer work with Lightning Locker.

Make sure all of your components are ready to move to LWS. You can use this workflow to evaluate your custom LWC’s.

Tools for Lightning Web Security

Wouldn’t it be great to quickly test your code to see if it’s compatible and is working correctly with Lightning Web Security? Guess what? You can! Salesforce created three tools to help you write and test secure code that works with Lightning Web Security. You can find two of these tools in the Salesforce Lightning Component Library. Let’s take a look at each of them.

Lightning Web Security Console
This new console helps you quickly find issues with the code in your components. To use it, simply toggle between LWC and Aura in the top right, then copy your code into the console, and select LWS: Enabled or LWS: Disabled from the dropdown menu. Then click Evaluate and your results show up in the field below. You’ll know in an instant if your code is compatible and secure.

Lightning Web Security Distortion Viewer
Lightning Web Security applies distortions to unsafe code when it finds it in your environment. These distortions modify behavior so the code can run safely. The Distortion Viewer provides explanations of the behavior unsafe code may cause, and what you can expect to happen when a distortion is applied. Distortion Viewer also provides suggestions of secure ways to implement your code.

ESLint Rules
If you’re using third-party components or libraries, you may not know what’s in the code you’re running. A great feature might be hiding something destructive. And you may be using unsafe practices in your own code without knowing it. To help mitigate this, Salesforce created ESLint rules for Lightning Web Security to help you know if you’re using distorted API’s in your code.

The Lightning Web Security Console runs the ESlint rules behind the scenes, and you can also us them locally while writing your code.

You install ESlint rules using npm in a terminal. Once installed, you can run the rules locally on your code or on third-party code. You can run them across a project or use them dynamically in VS Code.

For instructions, see Install ESlint Rules for Lightning Web Security.

Note

The new architecture was developed under the Locker name before the brand change to Lightning Web Security, so you see Locker used in code and in the npm package Readme file. However, the lint rules support Lightning Web Security, not Lightning Locker.

You can see ESlint rules in action in the LWS Console. Open the Salesforce Component Library and click the LWS Console tab. Then, evaluate this code:

export default class DistortionExample extends LightningElement {
   addContent() {
     const elem = this.template.querySelector("div");
     elem.innerHTML = "<script>malicious</script>";
 }
}

This is the result you get in the Linting Results panel:

warning: The elem.innerHTML setter is distorted by Lightning Web Security.

You can use the Salesforce Extensions for VS Code to show warnings when problems are found with linting rules.

That’s it! You learned about how Lightning Web Security works to keep your Lightning components secure, how the LWS enablement process works, and tools you can use to see if your components are compatible and secure. Lightning Web Security is an evolving feature, so keep an eye on the documentation for updates.

Resources

• Developer Documentation: Which Components Are Affected by Lightning Web Security
• Developer Documentation: Workflow to Try Your LWCs with Lightning Web Security
• Developer Documentation: Tools Support for Lightning Web Security
• Developer Tools: Lightning Web Security Console
• Developer Tools: Lightning Web Security Distortion Viewer