Salesforce LockerService is certainly the latest buzz in the SFDC Developer Community and it’s going to be a default starting this June. The upgrade is a powerful security architecture for Lightning components, that enhances security by isolating individual Lightning components in their own namespace.
As per the Salesforce LockerService Release Notes, the upgrade has enforced five security features in your code.

  • JavaScript ES5 Strict Mode Enforcement
  • DOM Access Containment
  • Stricter Content Security Policy (CSP)
  • Restrictions to Global References
  • Access to Supported JavaScript API Framework methods only

This article will help you tackle each of these security features and help you write a secure code for the Salesforce LockerService upgrade for your application. And as an add-on, I’ll also explain how we at Whatfix fixed the LockerService compliance issue.
Let’s get started with the security features.

JavaScript ES5 Strict Mode Enforcement

JavaScript ES5 strict mode is implicitly enabled under the new Locker Service. You don’t need to specify “use strict” in your code. Your code should follow the best practices required under strict mode.
"use strict";
Make sure your JavaScript code has “use strict”; at the top of the script, even though its not mandatory. (This upgrade should automatically add it, but making it mandatory  will help you in making your component or code LockerService ready)
Variables assignment and properties

"use strict";
foo = "bar"; //Error "Uncaught ReferenceError: foo is not defined" = "bar"; //correct
var foo = "bar"; //correct assignment

Deleting variables and functions

"use strict";
var foo = "bar";
delete foo; //this would fail with error "Delete of an unqualified identifier in strict mode"

Eval method
The most important restriction in a strict mode is that the “eval” will not work no matter how you try to define it. The keyword is completely prohibited.

"use strict";
var eval = "..";//Error - Variable name may not be eval or arguments in strict mode
eval("var foo = false;");//No error but the script is not evaluated

For the sake of simplicity, here’s a reference link, where you can find more information about Strict mode.

DOM Access Containment

With the Salesforce LockerService upgrade, a component can only traverse the DOM and access elements created by that component. This behavior prevents the anti-pattern of reaching into DOM elements owned by other components.

Before the LockerService, the JavaScript of one component had access to the DOM and JavaScript of the other components. But now, they all are restricted to their own code.

Although, System components still have access to everything. But, Custom components are restricted and do not have access to the real document and window object. Instead, they have their own secure document and window object. A snapshot of the core features is given below which has been taken from Salesforce Developer docs.
Core features of Salesforce LockerService


Stricter Content Security Policy (CSP)

Salesforce LockerService upgrade tightens CSP (Content Security Policy) to eliminate the possibility of cross-site scripting attacks. This is done by disallowing the unsafe-inline and unsafe-eval keywords for inline scripts (script-src). So ideally, the best way to go about with the upgrade is to eliminate the use of these keywords in your code and update third-party libraries to modern versions that don’t depend on unsafe-inline or unsafe-eval.
Currently, these CSP changes are only enforced in the Sandbox and Developer Edition orgs. As per the browser limitations, IE11 doesn’t support CSP so it is best to use a much more secure browser.


function foo() {
// this would throw error

This code will likely throw the unsafe-inline error in Salesforce Lightning. You will have to move the inline javascript to a different JavaScript file and then link it to your HTML page.

function foo() {
<script src="script.js"></script>

If you have inline JavaScript methods in your DOM elements, then you will have to replace them with listener code.

<body onload="main();">
<button onclick="clickHandler(this)"> Click for awesomeness!

The onload method will need to be replaced with a DOM listener.

document.addEventListener('DOMContentLoaded', function () {
      document.querySelector('button').addEventListener('click', clickHandler);

The danger of eval() is when it is executed on unsanitised values and can lead to a DOM Based XSS vulnerability.
LockerService headers have completely disabled the use of eval methods, so if your component or extension is using eval method, you may have to find an alternative.

Restrictions to Global References

Salesforce LockerService applies restrictions to global references. You can access intrinsic objects, such as Array. As for non-intrinsic objects, such as a window, Salesforce LockerService provides secure versions. The secure object versions automatically and seamlessly control access to the object and its properties.
To identify Lightning-specific issues use the Salesforce Lightning CLI tool to scan your code.

Access to Supported JavaScript API Framework Methods Only

With this upgrade, only supported JavaScript API framework methods are accessible.
The entire list of methods which are supported now after the Salesforce Lightning upgrade can be found in your Salesforce Aura documentation.
To find it, sign in to your Salesforce and go to this link
With all the security features, now I’ll tell you how we worked around the Salesforce LockerService upgrade.

How we tackled the Salesforce LockerService upgrade?

Whatfix’s interactive walkthrough on Salesforce is enabled via our extension. Due to the Salesforce LockerService, we started facing issues in traversing through the platform efficiently. Albeit, most of our code was compliant. But, at a few places, we were not aligned to the restrictions. Hence, our widgets failed to show up on Salesforce.
Below is a list of things we did to tackle the issue and make our extensions fully compliant with LockerService upgrade.

  • Whatfix uses Google Analytics to show reports of guide/walkthrough usage. But with the LockerService enabled, the Analytics stopped working properly. So, our first plan of action was to update our extension CSP headers to allow
  • Post that, we removed all the inline scripts (mentioned above) to a separate JavaScript file.
  • Themes and other customizations supported by Whatfix were evaluated inline when the page loads. The LockerService also doesn’t allow inline eval. So, then we changed the logic of our theme customizations to execute without the use of eval method.

And well, now Whatfix is fully compliant with Salesforce LockerService and works like a charm on Salesforce Classic and Lightning.
If you were facing similar issues and this article helped you, then I’d love to hear what you did in the comments below.
Also, do share and spread the knowledge with your fellow developers!
To check out our older articles on Salesforce, click here.

We at Whatfix believe that interactive walkthroughs will change the user experience of web applications by large. And our customer base speaks for itself, ranging from startups to SMB’s to Fortune 500 companies.
Are you looking for a solution to accelerate user adoption, training, documentation, and support? Well, then I urge you to try us out.

Related Articles