Impact of LockerService on Salesforce Lightning Components

Salesforce’s LockerService has only one true focus – to ensure the security of Salesforce Lightning Components.

Components are indispensable in today’s modular architecture oriented languages, frameworks, and platforms. The Salesforce platform offers the Lightning Component Framework to build Salesforce Apps with powerful functionality and deep customization. However, the components come from different sources, including third-party libraries, and such components usually come with its security vulnerabilities, loopholes, and challenges.

LockerService offers the right level of isolation to these components. This prevents the vulnerability on the part of any one component from compromising the security of the entire system. It is akin to providing a secure door for all rooms in the house, so that a burglar cannot access the contents of individual rooms even if he breaks into the house through the main door!

Related: Top 6 ways to find out if you are ready for Salesforce Lightning Experience

How LockerService Improves Security

LockerService isolates individual Lightning components in their own containers. It restricts access to supported APIs, and prevents non-published framework internals from accessing the component. A filtering proxy wraps all application events, allowing the code to see only what it has the right to access. However, it is still possible to communicate across components via namespaces.

LockerService also enables several new features, such as client-side API versioning similar to the REST API versioning, and running third-party JavaScript frameworks such as Angular and React.

Such a powerful and innovative architecture gives security a big boost, and makes adding new security features and policies easier. Benefits include:

  • Components are prevented from causing cross-site scripting (XSS) or other similar issues. XSS is one of the most common vulnerabilities plaguing software code, widely used by hackers to inject client-side scripts into viewed web pages and thereby bypass access controls such as the same-origin policy.
  • Components cannot have unrestricted access to other component’s rendered data.
  • Components cannot call undocumented or private APIs.

The Impact of System Mode and User Mode

Normally, a JavaScript of any component can call a JavaScript function of any other component, since all these are loaded in the DOM (Document Object Model). Likewise, a JavaScript can call any undocumented or private Lightning APIs, or access real DOM, to get rendered data from other components. While this makes things easy for the programmer, and enables unrestrained functionality, it leaves the door open for glaring security issues.

When LockerService is enabled, Salesforce-authored components and JavaScript run in “System mode,” similar to the Operating System’s system mode, and have full access to everything. Custom components, however, run in “User mode,” and do not get access to real Documents or real “window” object. Custom components rather get a custom DOM (“secureDOM”), custom Window.  Custom components can access other components’ DOM as long as they are in the same namespace but cannot access the DOM of other components, in other namespaces. To illustrate, the JavaScript in the “Map” component can access DOM of “Map” component, but cannot access the DOM of “Marketing” component. Custom components are also restrained from accessing “private” APIs, and can access only public and documented Lightning JavaScript APIs.

LockerService restricts cross-namespace access, and also global references. While it is still possible for a component to access intrinsic objects like “Array,” which are part of the language specifications, access to non-intrinsic objects (like “Window”) is blocked. The component rather gets a secure version of non-intrinsic objects, which versions automatically to the object and its properties.

The Impact of Strict Mode and CSP enforcement

LockerService draws its strength from established security practices such as Strict Mode and Content Security Policy (CSP) compliance.

LockerService enables JavaScript ES5 Strict Mode implicitly, making the code more robust and supportable than before. Strict Mode throws up errors that would otherwise be suppressed and that could leave security loopholes.

The latest Spring ’17 tightens Content Security Policy (CSP), by blocking unsafe-inline and unsafe-eval keywords for inline scripts. Eliminating these keywords in the script prevents cross-site scripting attacks. These CSP changes are applicable only to Developer and Sandbox edition orgs, as of now.

There is a catch though. Enabling Strict Mode and CSP requires basic JavaScript features such as MapObject and support for strict mode. LockerService relies on the browser for these JavaScript features. If the browser in use does not have these JavaScript features, LockerService cannot enforce all its security features, and it disables the features that cannot function. However, among the latest versions of the popular browsers, only IE11 does not support CSP. Using other browsers such as Firefox and Chrome pre-empts this limitation easily.

Usage of Third-Party Libraries

A big question emerging from LockerCode’s restrictive policies on custom components is the use of third-party libraries.

LockerService actually improves flexibility, by allowing different components to use different versions of a third-party library. LockerService enables full JavaScript module level isolation of window and document. With the locker tied to the namespace, different components can use different versions of a third-party library.

However, there are limitations too. One is the inability to use access libraries hosted on content delivery networks such as Google Maps. However, this limitation is only temporary. From Winter 2017, when the proposed “Safe Harbor” updates kick in, it will be possible to open up the Content Security Policy and access libraries from CDNs. It is possible to use third-party libraries such as React and Angular even now, but such services will have to be served from Static Resources and approved by security.

Application of Locker Service

LockerService works under the hood, with no change to public and documented APIs. The code runs directly in the same browser window like the other components in an application.

There is no change to the programming model either. However, it enforces new security rules, with modern JavaScript standards. Developers may have to upgrade their existing custom components for compatibility, depending on how the components were built in the first place.

LockerService is fast becoming a mainstream feature. Salesforce plans to auto-activate LockerService for all orgs in the Summer ’17 release. Until then, users can activate or deactivate the update manually as required, and evaluate its impact on the org. The Winter ’17 update would allow users to activate or deactivate LockerService seamlessly, under SetUp.

Trust is Salesforce’s USP, and a key element of trust is product security. LockerService goes a long way in affirming such trust among its user community.

Hope you did get to know about LockerService from this post. We would love to hear more from you. Contact us to tell your thoughts or share it with us on FacebookTwitter or our LinkedIn.

Related Posts:

Author : Nayab Naseer Date : 24 May 2017