Write Content Security Policy-Compatible Code
Learning Objectives
After completing this unit, you’ll be able to:
- Define what makes code CSP compatible.
- Explain how CSP helps prevent attacks through the browser.
- List how CSP protects against three types of attacks.
What Is CSP?
CSP is a computer security standard intended to help web designers and server administrators specify how content interacts on their websites. CSP helps mitigate and detect certain types of attacks, such as cross-site scripting (XSS), clickjacking, and other code injection attacks, resulting from execution of malicious content in the trusted web page context.
CSP provides a standard method for website owners to declare approved origins of content that browsers are allowed to load on that website. Covered content types include JavaScript, CSS, HTML frames, web workers, fonts, images, embeddable objects such as Java applets, ActiveX, audio and video files, and other HTML5 features. CSP is a set of security rules maintained by the World Wide Web Consortium (W3C) and is implemented in all major web browsers.
Why It's Important to Implement CSP
The Salesforce CSP policies are designed to help protect your applications and the data of your organization. While it may take some refactoring to make sure that your LWC applications are compatible with Salesforce's CSP policies, doing so will protect your applications and the data of your organization.
Salesforce has carefully audited our set of CSP policies to provide maximum security and to give developers freedom to build on our platform. Our CSP policies rely on Salesforce technologies such as LWC, Apex, Salesforce Lightning Design System, and others.
Implementing CSP as a configuration best practice means you stay in the loop as Salesforce works progressively to tighten CSP policies and add security measures that can be implemented inside of the Salesforce browser client.
How CSP Is Implemented in Salesforce
Blocking Inline Script
As part of our CSP implementation, LWC applications inside of Salesforce are blocked from loading an inline script, or calling a script from a template error or event handler. The LWC compiler will also reject attempts at including an inline script in Salesforce. This is intentional, because it is effective at blocking common XSS attacks.
Note the following JavaScript loads an inline script that is not blocked in any way. This example takes place outside of the Salesforce ecosystem.
<script>
const url = “https://safe-cdn.com/myScript.js”
loadScript(url, function() {
window.myScript.load();
});
</script>
In the next example, which uses LWC and the Salesforce ecosystem, note that the LWC compiler blocks an inline script from compiling.
Filtering a Dynamic Script
To aid developers with building complex applications on the Salesforce ecosystem, dynamic script evaluation through eval() is enabled.
The security architecture in Salesforce enables you to make use of eval() in an LWC application when needed without worrying about its abuse leading to security risks. When LWS is enabled, all custom code is running in the sandbox. Therefore, the eval() call is executed in the sandbox as well. When Lightning Locker is enabled, all custom code is run through Locker’s SecureEval() function. This scopes the context of the script to the current namespace sandbox. Here is a sample of how this code works.
renderedCallback() {
const str = document.querySelector(‘.title’).innerText = “test”;
eval(str);
}
Add Third-Party APIs to Allowlist
In order to add third-party APIs to an allowlist, you must first add them to CSP Trusted Sites. This option can be found under Setup in your Salesforce org.
You can use CSP Trusted Sites to add an API’s URL to the following CSP directives:connect-src, frame-src, img-src, style-src, font-src, media-src.
Securely Load External Scripts
Salesforce CSP protocols mean that even if you add a third-party URL to the CSP Trusted Sites allowlist, JavaScript files cannot be executed from that URL.
In Salesforce, third-party JavaScript files can be loaded only from static resources. This prevents the third-party script maintainers from tampering with a script, because URLs only reference locations and do not reference script content. This prevents duplicate scripts from being loaded on the same page.
Now that you understand how important client-side security development is to the security of your applications, you can take the appropriate steps to secure your development and protect your customers and data. Next, we take a look at how to do the same on the server side.
