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!
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.
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
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.
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.
Usage of Third-Party Libraries
A big question emerging from LockerCode’s restrictive policies on custom components is the use of third-party libraries.
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.
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.