Lightning LockerService is a security architecture for Lightning components, that enhances security by isolating individual Lightning components in their own namespace. LockerService also promotes best practices that improve the supportability of your code by only allowing access to supported APIs and eliminating access to non-published framework internals. Enabling LockerService enforces the following security features in the components:
- DOM Access Containment
- Stricter Content Security Policy (CSP)
- Restrictions to Global References
LockerService enables :
- Client-side API versioning similar to REST API versioning
- Faster security review
- Better and more secure JS development practices
- Running 3rd party JS frameworks like React, Angular and so on
- Easily adding or removing new security features and policies
It prevents components from:
- Causing XSS and similar security issues
- Reading other component’s rendered data without any restrictions
- Calling undocumented/private APIs
With the LockerService turned ON
- Salesforce-authored components and JS run in “System mode” (similar to the Operating System’s system mode) and have full access to everything.
- Custom components run in “User mode” and don’t have access to the real Document or real “window” object.
- Custom components instead gets a custom DOM (“secureDOM”), custom Window and so on.
- Custom components can access other components’ DOM as long as they are in the same namespace but won’t be able to access other components’ DOM that are in different namespace. For example, JS in the “Weather” component can access DOM of “Map” component, but won’t be able to access DOM elements of the “Finance” or “button” component.
- In addition, custom components will only be able to access public and documented Lightning JS APIs and won’t be able to access Lightning framework’s “private” APIs.
- “Use strict” and CSP are enabled and enforced for security of all components.
LockerService enforces security in Lightning Experience, Salesforce1, Template-based Communities and Standalone Lightning apps. It doesn’t affect Salesforce Classic, Visualforce-based communities, Sales Console, or Service Console, except for usage of Lightning components in Visualforce in these contexts.
IE11 doesn’t support CSP, so Salesforce recommends other supported browsers for enhanced security.
A component can only traverse the DOM and access elements created by a component in the same namespace. This behavior prevents components of different namespace from reaching into DOM elements owned by components in another namespace.
This feature prevents components installed from a managed package to access DOM of components belonging to other namespace.
Preventing cross component access makes the components loosely coupled and less likely to break.
Access DOM elements using the following methods :
- component.getElements(): Returns the elements in the DOM rendered by the component.
- component.find(): Returns the element from the component, identified by their aura:id attribute.
- component.find(“div1”).getElement(): Returns the DOM element for the div
- event.getSource().get(“v.name”): Returns the name of the element that dispatched the event;
Invalid DOM Access :
- component.find(“button1”).getElement() : when using a <lightning:button>, this method will throw an error as it is trying to access the DOM of the <lightning:button> which is in the lightning namespace.
- document.getElementById / document.getElementByName/ document.getelementsbyclassname : these are invalid methods to access DOM elements with LockerService enabled.
Use only the valid methods to access the DOM elements in the component.
Ensure that all variables are declared with the ‘var’ keyword. With LockerService enabled the lightning component will throw a runtime error on load if variables are not declared with the ‘var’ keyword.
Using 3rd party JS Libraries
Most recent version of the third-party libraries should be used that don’t depend on ‘unsafe-inline’ or ‘unsafe-eval’. Other libraries may work, but have not been tested. There will likely always be supported as long as they are secure. Insecure libraries won’t work.
You can find the LockerService documentation here.