Locker Services and Lightning Components

LockerService brings multi-tenancy to the browsers. This is done by sandboxing of code and isolation of  elements, thereby setting them apart from the rest of the system. Locker acts as a Virtual iframe that helps to bring all the security benefits –  minus the drawbacks of UI for an iframe. In fact, In LockerService, all components are loaded in the same DOM and hence is this found to be lighter in nature – compared with Lightning Container Component.

LockerService for businesses are enabled for components with API version 39.0 and lower. This covers those components created before Salesforce Summer 17 release.  If your org has too many Lightning components and live users are using application and component – the users are flashed with a warning on the Salesforce org “Lightning LockerService will be enforced on June date_x.”

Consequently, the Locker issues may simply stop the components or the Lightning page – with Locker services enforced by Salesforce. Here is a use case of enforcement of LockerService on Lightning component.

Use Case on LockerService

Primarily, the benefit of the LockerServices is to offer security benefits. Let us explore “What are the security benefits?”.

What are the security benefits of Locker Services?

Locker source is open-source Javascript files maintained by Salesforce. When Single Page Applications (SPAs) are built using Lightning components, then Security can be enforced by LockerServices. Locker makes use of Content Security Policy (CSP) of the browser. But there are some primary risks that Locker Service is trying to avoid. Let us now find them one by one.

Primary Risks Locker Service is trying to Avoid

The primary risk that Locker is trying to avoid is that of Cross Site Scripting (XSS). The Cross Site Scripting is the most common problem of web browsers. Let us find more details on “What is Cross-site scripting?”.

In cross-site scripting there is a perpetrator, who after the discovery of some vulnerabilities of the website, injects some code and as the users come across this sort of malicious content this will allow to access the cookies and obtain personal information about the users.

This also helps it to be prevented against clickjacking as well as other attacks with code injections that result in the execution of malicious content in the context of the trusted webpage.

In addition to this,  coexistence of components from various vendors – to exist in the same web page. With its help namespace can be added to its components. This way it prevents the data access from other components – with DOM not created by your component.  Next, we speak about Locker Compliance and reworking of LCs.

Which all Locker Components need to be reworked, so as to make Locker Compliant ?

The Salesforce admin or the developer can enable the Locker services with critical updates and test the component/application – whether it is functional.

Next we move to CSP Policy, that is implemented in the modern applications.

How to implement CSP in the modern applications ?

CSP is supported by all the modern browsers – Firefox, Chrome, Safari and others. CSP can be enforced by an HTTP header, rule pattern and a name. A ruleset defined browser can be used for prevention webpage downloading of malicious content from unknown sources.

If any CSP Script Violation occurs in Chrome, then the following message appears in the Chrome developer tool. ‘

Refused to load the script ‘script-uri’ because it violates the following Content Security Policy directive: “your CSP directive”.

When using Firefox, a message as following is displayed by the Web Developer Tool.

Content Security Policy: A violation occurred for a report-only CSP policy (“An attempt to execute inline scripts has been blocked”). The behavior was allowed, and a CSP report was sent.

The LC code can be broken under Locker, let us now find the causes for that.

What are the Causes for broken LC Code in Locker ?

The causes for broken LC code are as follows:

• ESS Strict Mode Compliance of Javascript
• Third-party libraries not locker-compliant
• Loading Images or JS libraries from CDN or an external website

ESS Strict Mode Compliance of Javascript

You need to check with Javascript strict mode rules from:

An example to cite here is without the use of Var keyword for declaration of variables, the Javascript code breaks, with Locker on.

Third-party libraries not locker-compliant

One must ensure that any third-party libraries must be checked for working in Locker Service. How to do this ? The answer is:

• Download the library and upload in static resource
• Static resource is taken inside the component to test all the functions

The developer must have proficiency in LC development and Javascript development and can refer to this site:

Loading Images or JS libraries from CDN or an external website

The assets and images must be ensured to be loaded by loading from Salesforce Strict Resources only. However, an administrator can configure trusted sites that falls under the CSP trusted sites.  

Summary

When the user creates a Lightning component then there is an API version. The LockerServices is on or off based on this API version. Summer 17 release of Salesforce has an API version 40. Anything that has API version 40 or higher will have LockerService enforced otherwise it is ignored.

From the security perspective, it makes sense to move all your components to LockerServices.
The best way to answer queries on any issues created by Locker Services is obtained in Salesforce stackexchange.