Lightning LockerService

LockerService in Lightning is a powerful security architecture for Lightning components implemented to make lightning components secure.  Basically, LockerService enhances its security by isolating the individual Lightning components in their own namespace itself.

Locker Service tightens Content Security Policy (CSP) to eliminate Cross-Site Scripting (XSS), clickjacking and other code injection attacks resulting from execution of malicious content in the trusted web page context. In addition to prevention against vulnerabilities, Locker provides two key functions (a) by name spacing your components (like Apex name spacing) and (b) by isolating component JavaScript to only interact with your own component.

LockerService enforces security feature in the following items: 

1. Lightning Experience.
2. Salesforce1.
3. Template-based Communities.
4. Standalone apps.

LockerService has no control over Salesforce classic, Visualforce-based communities, Sales Console except the usage of Lightning components. Locker Service uses JavaScript strict mode, which makes it easier to write secure JavaScript. For instance, in normal JavaScript, if we mistype a variable name, it creates a new global variable, but in strict mode this will throw an error by making it impossible to create a global variable accidentally.

Prevention by LockerService: 

LockerService uses various technologies and techniques to prevent the components from performing the following:

1. Causing XSS and similar security issues.
2. Preventing access to the part of the DOM that does not belong to your component.
3. Calling Undocumented or Private APIs.
4. Reading other Components’ rendered data.

LockerService Activation/Deactivation: 

We can enable the LockerService under Critical updates. It is intended to be activated automatically for all the orgs in the Summer ’17 release. So, before Summer ’17 release, we can manually activate and deactivate the update to check the functionality by testing the application or Lightning component. To activate the critical update, perform the following steps:

1. From Setup select Critical Updates.
2. Click Activate/Deactivate to Enable/Disable Lightning LockerService security.
3. After activating the LockerService, refresh the page to check the functionality.

LockerService control over Managed Packages:

To control the components installed from Managed Package to enforce the LockerService,

1. From Setup select Lightning Components by typing the same in the Quick find box.
2. Select the Enable LockerService for Managed Packages checkbox to enforce LockerService for components installed from a managed package. This checkbox is only available after the critical update is activated.

LockerService turned off: 

Let us consider, for an instance, a Lightning app which has four components: Button, Location component which internally has Map sub-component and a Degree component.

*Real DOM

In the above scenario, when the LockerService is turned off:

1. Any JS of any component can call any JS functions of any other component as they are all loaded in the DOM
2. Any JS can also call any undocumented/private Lightning APIs
3. Any JS can access real DOM and get rendered data from other components.
4. Components that are not security reviewed can potentially have security issues.

When the LockerService is turned ON: 

1. Custom components run in “User mode” and don’t have access to the real Document or real “window” object. Instead, it gets a custom DOM (“secureDOM”) and custom Window.
2. Custom components can access other components’ DOM if they are in the same namespace but won’t be able to access other components’ DOM that are in different namespace.

For an instance: JS in the “Location” component can access DOM of “Map” which is of sub-component, but won’t be able to access DOM elements of the “Degree” or “button” component.

Example:

In the below example, ui:button, which uses a div in the namespace of “c”, the console.log differs for windows, and  document and div when LockerService is turned ON. Also, custom component JavaScript tries to access the DOM by performing div.parentNode.innerHTML to get the buttons inner HTML but it can’t read the innerHTML since it is in different ”ui” namespace.

LockerService.cmp:

<aura:component implements="force:LightningQuickAction"> 

<ui:button press="{!c.doInit}"> 

        <div class="testclass">Locker Service</div> 

    </ui:button> 

</aura:component> 



LockerComponentController.js: 

({ 

doInit : function(component, event, helper) { 

console.log(window.toString()); 

        console.log(document.toString()); 

        var div=document.querySelector(".testclass") 

        console.log(div.toString()); 

        console.log(div.parentNode.innerHTML); 

} 

}) 

LockerComponentApplication.app: 

<aura:application > 

<c:LockerService></c:LockerService> 

</aura:application> 

In the below Console.log,  when the “Locker Service” button is clicked and when the LockerService is turned OFF,  div.parentNode.innerHTML is returning innerHTML of the parent element which is “Locker Service”.

In the below Console.log, when the “Locker Service” button is clicked div.parentNode.innerHTML doesn’t return the innerHTML of the parent element since it is in Secure DOM and the button is in “ui” namespace.

LockerService Availability: 

1. In the current Spring ’17, LockerService critical update will tighten Content Security Policy(CSP) and it is enforced only in Sandbox and Developer edition orgs.
2. In Summer ’17, LockerService will be auto-activated for all orgs with no option to disable.

Advantages: 

1. Cross-site scripting (XSS) and template injection are no longer possible.
2. Eliminates server-side action invocation/spoofing.
3. Eliminates DOM scraping vulnerabilities.

References:

• https://developer.salesforce.com/docs/atlas.en-us.lightning.meta/lightning/security_code.htm
• https://developer.salesforce.com/blogs/developer-relations/2016/04/introducing-lockerservice-lightning-components.html