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.
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:
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?
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.
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.]
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.
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.
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.