Logging into a Salesforce org these days yields a warning that says “Lightning LockerService will be enforced on June date_x.” If your org has too many Lightning components and if your application or component is used by live users, pay attention. The Lightning page or the component might stop working due to Locker issues once LockerServices are enforced by Salesforce. Here are answers to your top five Lightning LockerService questions. (Skip to the end for a workaround.)
1. What security benefits does Lightning LockerService provide?
Lightning LockerService enforces security into Single Page Applications built using Lightning components. Locker uses browser CSP (Content Security Policy) to prevent a web page against 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: namespacing your components (similar to Apex namespacing) and isolating component Javascript to only interact with your own component. This allows the secure co-existence of components from multiple vendors on the same web page and ISV’s to build components to publish on the AppExchange.
LockerService is a collection of open source Javascript files and is maintained by Salesforce here. If you are a Javascript geek, check out the code.
2. How is CSP (Content Security Policy) implemented in modern applications?
Content Security Policy is enforced by adding an HTTP header with name “Content-Security-Policy” and defining a rule pattern. Based on the ruleset defined, the browser restricts the web page from downloading malicious content from unknown sources.
A simple rule would look like:
default-src 'self';
This means allow everything (images, Javascript and CSS), but only from the same origin.
For example, to implement this on an Nginx server, the following is added to the header:
add_header Content-Security-Policy "default-src 'self';";
If the script tries to violate the rule, the browser displays an error on the console.
In Chrome, when a Content Security Policy Script Violation happens you get a message like this one in the Chrome Developer Tools:
Refused to load the script ‘script-uri’ because it violates the following Content Security Policy directive: “your CSP directive”.
In Firefox you might see a message like this in the Web Developer Tools:
Content Security Policy: A violation occurred for a report-only CSP policy (“An attempt to execute inline scripts has been blocked”). The behavior was allowed, and a CSP report was sent.
3. How do we identify what Lightning components need to be reworked to become Locker compliant?
Salesforce developers or admins can enable LockerServices under critical updates and test the application or Lightning component to see if it’s still functional.
4. What browsers support CSP?
The above information is taken from canisue.com. You can read further on what’s supported in specific browsers here.
5. What are common causes for your Lightning component code to break under LockerServices?
1. Using third party libraries that are not Locker compliant – Any third party library adopted must be checked to ensure it works inside Salesforce LockerService. But how do you test this?
- You will need to download the library.
- Upload it as a static resource.
- Reference the static resource inside the component and then test all the functions with LockerService enabled. This requires a developer skill set with extensive knowledge of both Javascript and Lightning component development.
Currently, the only reliable reference to research if something is supported is documentation located here. There is also a list of libraries found to work published here. [Please note the disclaimer that future versions are not guaranteed to be supported.]
2. Knowing if your Javascript is ES5 Strict Mode compliant – Check the Javascript Strict Mode rules documented here. A common example is if you do not use var keyword to declare your variables, your Lightning code will break with Locker turned on.
3. Loading Images and other JS libraries from a CDN or an external website – The easiest way to ensure your images and other assets are loaded, is to load from Salesforce Static Resources only. However, as an administrator of the org, you can configure trusted sites under CSP Trusted Sites.
To use third-party APIs that make requests to an external (non-Salesforce) server, add the server as a trusted site. If you are building a Lightning component, Salesforce has a CLI to check your Javascript is Locker compliant.
A Workaround
LockerService is enabled for all Lightning components with API version 40.0 (the version for Summer ’17) or higher. LockerService is NOT enabled for components with API version 39.0 and lower, which covers any component created before Summer ‘17.
To enable LockerService for a component, set the API version to 40.0. You can disable LockerService for a component by setting the API version to 39.0 or lower for the component. It’s a good idea to upgrade to V40 to secure your components against various vulnerabilities. Upgrading to v40 from v39 would mean taking the step to ensure your Lightning components work under LockerService.
Final Thoughts
LockerService for developers is a headache and a hurdle, but for end customers it’s an additional layer of security that protects your application from multiple threats. Javascript has extensive API and wrapping all of the library attributes and functions is not a simple task. The best way to get answers to Locker related issues has been a post on Salesforce stackexchange. I want to take this opportunity to personally thank all the community members who have contributed to the issues on the stackexchange site and the Salesforce engineers who have taken time to respond and address issues.
References
LockerService and Lightning Container Component
Want to ensure your app stays functional no matter the update? We’ve got you covered. Check out www.codescience.com/services to see how we can help.
