Lightning Locker- A question in every Lightning Developer’s mind for which they are still seeking the clear explanation. With a series of posts, I will try my best to explain this in simple words with a few examples along the way.
Not simple enough? No worries!! Let’s take one step at a time.
Step #1- Why there is a need for Lightning Locker? – Let’s go through this post to find out the answer of this question.
Why do we say that browsers can be insecure?
What is cross-site scripting(XSS)?
<script>alert('you are hacked');</script>However, in real life, the hacker can inject a script to send the user’s credential to an external server.
http://sfdcfacts.com?postId=<script>alert('you are hacked');</script>
What is the solution?
XSS attacks are the main challenge in the web-development world and there is no straightforward and 100% working solution to prevent these attacks. The common technique to avoid these attacks are:
- Data Validation – Validating input field data before saving it or processing it
- Data Filtering – Filter malicious keywords from input field data
- Data Escaping – Character escaping is another popular solution where some characters are replaced with another word/character. It is widely supported by all popular languages.
- Deep Testing – A thorough and deep testing is a must to test this attack.
"use strict"; x=5;//will throw an error as x is not declared
where below code will not throw an error:
"use strict"; var x=5;//will work as x has been declaed before value assignment
- Declare a variable before value assignment.
- Attach the variable to the window object, to make it global.
How it impacts your Lightning Components?
No, it’s much worse. How? Let’s see.
Lightning Framework is a component-based framework, where multiple components are placed together on the same page to give you a combined output. These components can be:
- Base lightning component (lightning namespace like lightning:button)
- Other out of the box components (like force, ui, aura namespace)
- Custom components (You org’s custom components, generally from “c” namespace)
- Managed/Unmanaged package components
Having these many different components, which belongs to different namespaces on the very same webpage can be very insecure as:
- One component can traverse the DOM of another component. That means my managed package component can read or traverse the DOM of my Org’s custom components.
- Components can call private APIs.
- If strict mode is not enabled (without lightning locker), can lead to other security issues.
Let’s take below-shown lightning component as an example:
In this example, I have 4 different namespace components in one single custom component. If Lightning Locker is NOT enabled, then you will see a DOM something like below:
So, every component belongs to the same window object hence they all will have access to each other. My managed package component can traverse through my custom component or vice versa. This is very insecure as I should not allow a managed package to read my component.
To change above behavior of Lightning Framework, Lightning Locker was introduced which restrict access to your DOM elements from a different namespace and at the same time gives complete accessibility to same namespace components.
This post explains the need of Lightning Locker Services. I will be writing follow up posts in this series to explain the Locker Service Advantages and Disadvantages, Security mechnism comes with locker services and in the end an example of Locker Service Implementation. Please do share your feedback in the comments.
#LearnShareRepeat – Let everyone learn about Lightning Locker by sharing this post.