Content Security Policies in Sitecore
Security is a fundamental expectation of an application. Unfortunately, most applications are generally vulnerable to attacks; a small loophole in your website can erode the trust of your users.
For example, take the case of a Cross-Site Scripting(XSS) attack. In this, the attacker launches a malicious script on an unsuspecting user. Once the script is launched, the end user’s browser has no way of knowing if the script can be trusted and hence runs it.
Today, websites have to access a lot of assets from external resources. It could be external CDN links, Google Analytics scripts, APIs, common modules, or even fonts. Attackers take advantage of this requirement and launch XSS attacks to gain critical information from the website.
To prevent this, you need to adopt a CSP(Content Security Policy). It is a standardized set of rules that defines how the browser intercepts data or requests from your website. It eliminates unauthorized access, avoiding attacks and injection vectors.
How does a Content Security Policy help?
When you include CSP into your website, the browser inspects every element that it comes across and prevents unauthorized elements, be it images or other executable scripts. In other words, CSP prevents the browser from downloading or executing unauthorized scripts. Through CSP, you construct a list of rules for the browser to follow for the website.
With CSP in action, you can frame policies that allow access to certain kinds of resources on the internet. The resources are split into various directives(types of resources you request the browser to fetch).
Implementing CSP to your website involves adding the HTTP header to your server configuration. You can use Sitecore’s CSP headers to enforce access to specified resources or just report violations. A simple example of a CSP header is as follows -
<add name=”Content-Security-Policy” value=”default-src ‘self’”/>
So if you are hosting JS and CSS files externally, you can list them under default-src so that they are the only exempted resources that are allowed by the browser for your website.
Different Directives in the CSP Field
Default-src - This is the most basic directive in CSP and is used for fallback purposes. In case the other directive locations (for instance script-src or image-src) are not specified, it is directed to the default-src source. You can use default-src ‘self’ to allow content access from the current origin and use default-src ‘none’ to block all script, images, and other iframe directives from all sources including the current origin.
Script-src- This directive whitelists script tags (predominantly JS tags) from all sources. You can use script-src ‘self’ in the response header to allow content only from the current origin. In case you host JS files externally, it is required to provide the domain name for the JS files like script-src trustedscripts.com.
Style-src - This directive is used to whitelist stylesheets. To allow stylesheet resources from all origins, you can use the style-src *; directive.
Media-src - With this directive you can specify locations to retrieve rich media content like videos and large infographics
Object-src - This directive whitelists the sources for plugins to be used by your site.
Child src/frame-src - This directive supports the sources for frame/iframe elements. With the frame-src being deprecated in CSP level 2, it is best to use both these tags subsequently with identical values to receive iframe resources from specified origins.
Let us now try to understand the different categories of origin specified after the directive terms - the source expressions.
What are Source Expressions?
Source expressions are variants of sources from which content is allowed in a directive. It is the part that comes after the content directive. The most commonly used source expressions are -
self - This expression allows content from the current origin/ host origin.i.e styles, images, iframes, and scripts from your localhost or domain host.
unsafe-inline - This keyword allows all inline styles and scripts. It also allows all JavaScript event handlers by default. For instance,
<button onclick="clickable">Click me</button>.
unsafe-eval - Used for methods like eval(), settimeout() and setinterval() handlers. Commonly used in script-src directive.
none - Prevents resources from all kinds of origin. Be it internal or external stylings or scripts.
Reporting and Testing CSP
For testing the CSP just open your preferred browser and open inspect element or Chrome’s developer tools. Before that, enable your CSP with different directives and use the source expression ‘none’, so that no outbound resource requests are made. Now you will see a message resembling the one below shooting up in the console.
“Refused to load the script 'script-uri' because it violates the following Content Security Policy directive: "your CSP directive”.
Also, coming to reporting, violation reports are not recorded by default. So the report-uri directive is used along with at least one URL to deliver violation reports in case the browser makes outbound requests to external sites.
Content-Security-Policy: report-uri <uri>;
Where uri is the URL where the violation reports should be posted. You can also specify multiple URLs. The violation reports will be generated in the form of a JSON file and posted in the specified URL.
Combat Click-Jacking Threats with Sitecore’s X-frame
Sitecore has recently introduced an X-frame-option that is added by default to the web.config as an HTTP module. Adding the X frame option instructs your browser how to behave with your website’s content. This is used to prevent clickjacking, where attackers embed isolated third-party content into your website using iframe tags. When it is clicked, your system information can be compromised by the attacker. Real-time examples of iframe include social media sharing buttons, Google Maps embed, audio/video players, third-party advertising channels, and OAuth implementations.
Wrapping Up
The CSP is a reliable method to fight against XSS attacks and other injection vectors. While the CSP implementation can quite be confusing and even induces a possibility of breaking your site, there are numerous tools and patterns that help you make your website a safe one. With the introduction of Sitecore’s content security module, it is now easy to manage CSPs for a site or you can specify individual CSPs for a page, making each page on your site get resources from different trusted sources.