by Jordan Ojeda, Force.com Developer at Nubik
Everyone who has developed any application, feature, improvement or even those who have been indirectly involved in any development process may know that security is extremely important when it comes to coding. As developers, we have to act as if we were the captain of a ship! We have to protect it, we need to defend it from invaders! Fortunately, we don’t need to pay a float of stormtroopers to help us defend it (would be cool though!). Instead, in our case, we need to guarantee that any malicious code won’t be able to take advantage of any weaknesses we might have in our code. Yes, that probably sounds a little bit complicated, but Salesforce is here one more time to give us a hand with this complex task, this time by allowing us to leverage a feature called LockerService (LS).
LockerService is a security feature introduced as optional in summer ’16 and enforced (at least that was the initial plan) in Winter’17 for all organizations. The main idea of LockerService is to provide an extra layer of security intended to protect our organizations against certain vulnerabilities like, Cross-Site Scripting (XSS), components reading from other components, components calling other APIs under the hood, or similar security issues.
This article is not intended to be detailed description about the characteristics offered by LockerService, instead I just want to give you in an overview; some tips about how to know if your code complies with this enhancement, and if not, what to do, and some useful references to understand how this works. To see technical details about how it works you can go here.
One of the biggest challenges when it comes to LockerService is that all the front end libraries you use need to support it, as a result they have to follow the security criteria enforced by this feature. Otherwise you might have issues with some of them after LockerService activation. Sadly, there is not a perfect verification tool to determine if a third-party library complies with all the rules mandated by LockerService. In this case probably one of the best way to proceed is by just testing it.
We could have three different scenarios:
- You already have your application developed, but you haven’t tested it again since LockerService was activated. In this case just give it a try to see if you can detect any error, hopefully you won’t ☺. In case you find any problem, well… you will know that it’s time to grab a good cup of coffee and do some adjustments!
- You have been developing your app, but you didn’t even know about LockerService. Most likely your application is not failing so far, so maybe you are on the right track!
- Or if you have a plan to use a third-party library for an incoming development. In this case, the first thing to do is to ask yourself: Do we really need to use this library? Is there any way we can use something provided by Salesforce? If you answer with an immutable YES, probably the best way to go is just by creating a simple example mock up of the way you will need to use it.
Unfortunately, we don’t have an official and unified document that we could use to determine if a library complies with LS, but at least, following this practice you might be aware of any possible problem that you could face by using this third-party library.
You can check the official documentation for further information, but here, some of the main requirements from LockerService:
|DOM Access Containment||
|Secure Wrappers for Global References||
By needing to use a third-party library, in the worst case scenario there is a chance it does not comply with some of these rules. Even though LS should be the first mechanism of isolation to rely on, in these cases we can use Lightning Container Component Isolation instead. The Lightning Container Component is a component that embeds content in an iframe, wrapping it up in a separate context. This component can be used to sandbox other components or apps that don’t work with LS. More information here.
As we have seen so far, LS sounds like an extra load of work for us, but it’s actually leading us to a proper way to work (remember when it comes to software development, security is a big and tough theme) just by complying with good standards. In order to try to minimize this “extra work,” Salesforce has been providing us with some features and updates that can smooth the transition to Locker Service.
LockerService API Viewer:
This viewer lets us explore the properties available on the secure version of the DOM API elements. This way we can compare both the secure versions vs. the browser-supported versions in order to prevent incompatibility issues or to address them early. For more information go to this link.
Content Security Policy Decoupled From LockerService:
Content Security policy restrictions are expected to be part of LS, nevertheless the Salesforce team has decided to separate this and provide us with two critical updates that are not enforced for production organization in Winter ‘18.
- Enable Stricter Content Security Policy for Lightning Components
- Enable Stricter Content Security Policy for Lightning Components in Communities
You can see more information about these update in the official documentation.
Salesforce DX and Lightning LockerService:
Salesforce used to provide a tool to scan the code of our Lightning components looking for general issues with LS. Nowadays this tool is deprecated, but the good news is that Saleforce DX will provide a refreshed alternative that can help us to verify if our code works with this feature.
Salesforce DX will allow to run a static analysis that by default is based on the recommended best practices, and on LS requirements. The command to run is “lightning:lint” (check here for more details), and the rules used to evaluate the specified component can be configured according to our needs!