SalesforceSummaries: a series delivering key insights from Salesforce YouTube videos, to save you time as you keep up to date with the latest technological changes within the Salesforce ecosystem.
LockerService is a relatively new security feature from Salesforce that enforces JavasScript best practices for Lightning components.
Video: ‘Introduction to LockerService’
Presenter: Farhan Tahir
Date: November 29 2016
Time: 18 minutes
Key terms: LockerService, cross-site scripting, real DOM, security, isolate namespaces
- @3.10 — An example of an XSS attack is: let’s say you have an eCommerce website that has been attacked by XSS. When a customer goes to your website and inputs some sensitive data (e.g. their billing information), that data doesn’t go to your website anymore, it will go to the attacker.
- @3.45 — Out of all website attacks, XSS accounts for 84% of them.
- @4.10 — In the example below, the Lightning App has multiple components from different namespaces. The issue here is that all of these components have *unrestricted *access to the DOM. This means that any component can read the rendered data from another component. Note — the components cannot access server data.
- @4.35 — Another issue is that none of these components are siloed in anyway; which means if there is an issue in any component, then that has the ability to affect other components.
- @5.00 — In order to solve these issues, LockerService has been introduced; which will be enabled automatically for Lightning components on API version 40 and above. For components on an API version less than 39.0, LockerService is *not *enabled. You can upgrade the API version of Lightning components to be at least API version 40, although you should do tests first.
- @5.50 — LockerService enforces strict mode and enforces best practice. With LockerService, you have to define variables and types, so a strongly-typed paradigm is adopted. Also, if you are using any third party libraries in your components, then they too must use strict mode.
- @6.20 — LockerService limits access to the DOM to your own namespace, so that you can’t create data off of other components.
- @7.50 — If you use third party libraries, you should ensure that you are on the latest version.
- @8.20 — What LockerService enables one to do is to expedite testing of your code. This will be helpful for ISV partners because the time taken to test code, with LockerService, will reduce rapidly.
- @9.45 — In this particular example, the weather and map components share the same namespace and the finance component has a different namespace.
- @10.00 — This is what the workings of the app look like when LockerService is not enabled:
- @10.46 — With LockerService enabled, the workings of the app look very different:
The UI button on the right side of the screen, which is a Salesforce provided component, runs in system mode. Access to system mode enables one to have access to the DOM.
When the weather or map components (on the left side of the page) request the DOM, they don’t get the real DOM as they get the shadow (secure) DOM instead. In addition, the elements of namespace1 can no longer access the elements of namespace2 and vice versa. Every component has been isolated within its own namespace.
- @12.30 — Because IE 11 doesn’t support CSP (Content Security Policy), starting from December ’17, you won’t be able to use IE 11 for Lightning Experience.