What is a Content Security Policy (CSP)?
A content security policy (CSP) is a security mechanism for websites. It specifies the sources from which a website is authorised to load resources such as scripts, images or style sheets. Through this definition, the CSP protects against various attacks, in particular cross-site scripting (XSS), by restricting the execution of untrusted code. In short, the CSP helps to increase the security of a website by controlling what types of content are allowed to be executed on the page.
Why do you need a content security policy?
A Content Security Policy (CSP) is important because it provides a crucial protection mechanism for websites. There are several good reasons to set one up:
Protection against cross-site scripting (XSS): XSS is a common method of attack in which malicious JavaScript code is usually injected into websites. A CSP helps to minimise such attacks by controlling which sources and embedding types for scripts are permitted on a page.
XSS (cross-site scripting) is a type of attack in which attackers inject malicious code into a website, which is then executed by other users. Here is a simple example:
Attacker creates a comment: suppose there is a website with a comment function. An attacker enters a comment as follows:
<script>
alert('You got hacked!');
</script>
Comment displayed on the website: When another user views this comment, the injected code is executed and a pop-up window appears with the message "You got hacked!".
In this example, the attacker uses the comment function to inject malicious JavaScript code. The code is then executed by other users who view the comment, which can lead to potentially harmful actions.
Limitation of clickjacking attacks: CSP enables control over which domains are allowed to embed content in iframe elements to prevent clickjacking attacks.
Clickjacking is a type of attack in which a malicious actor attempts to manipulate a user's actions on a website by fraudulently obscuring the user interface. Here's a simple example:
Attacker creates a fraudulent website:
The attacker creates a website with an invisible overlay that mimics a trusted website, say "www.bank-example.com".
<style>
#overlay {
position: absolute;
top: 0;
left: 0;
width: 100%;
height: 100%;
opacity: 0.5;
z-index: 9999;
}
</style>
<div id="overlay"></div>
<iframe src="http://www.bank-example.com" width="100%" height="100%" frameborder="0"></iframe>
User visits the fraudulent website: The user visits the attacker's fraudulent website, where the overlay covers the real website.
User performs unintended actions: Since the overlay is invisible, the user could unknowingly perform actions on the real website while thinking they are interacting with the fraudulent website.
In this example, the user may think they are interacting on the fraudulent website when in fact the actions are being performed on the real website. Clickjacking attacks can be prevented by implementing measures such as the use of the X-Frame-Option header to restrict the embedding of the page in IFRAMEs.
- Restriction of insecure connections: CSP can be configured to only allow resources to be loaded via secure HTTPS connections, which improves the security of data transmission.
- Protection against malicious content: By precisely controlling the permitted sources for resources such as images, scripts and stylesheets, CSP helps to reduce the risk of malicious or unsafe content.
Overall, a content security policy helps to strengthen the security and trustworthiness of a website by enabling control over the sources of resources and protecting against various types of attacks.
How to set up a content security policy with TYPO3?
TYPO3 had no native support for setting up a content security policy until version 11. It was possible to set one up via manually set web server headers, but this had a decisive disadvantage, namely the lack of support for "nonce" values when integrating inline scripts or CSS blocks. Since TYPO3 12, this feature is now integrated and you can set up a fully-fledged content security policy including "nonce". TYPO3 12 also offers a check tool in the CMS with a log of violations of the CSP.
A "nonce" is an abbreviation for "Number Used Once". In information security and cryptographic contexts, a nonce is a random or uniquely used number or character string. The main characteristic of a nonce is that it is only used for a limited period of time or for a specific application. This means that it is not reused and therefore offers additional security.
A Content Security Policy (CSP) can use a nonce value to control the execution of inline scripts. By adding a nonce attribute to a script tag, the script is only executed if it contains the same nonce value that is in the web server's page delivery security header, which helps to prevent XSS attacks.
Example of a CSP header with a nonce:
Content-Security-Policy: script-src 'nonce-abc123'
Here, the script is only executed if it contains the correct nonce, in this case "abc123". This nonce value must change with every page load and must be in the web server header as well as in the inline script of the website frontend. This function is therefore not feasible without the support of the CMS.
To set up a CSP in TYPO3 12, it is sufficient to store a csp.yaml file in sites/<my_site>/csp.yaml with the following content:
# Inherits default site-unspecific frontend policy mutations (enabled per default)
inheritDefault: true
mutations:
# Results in `default-src 'self'`
- mode: set
directive: 'default-src'
sources:
- "'self'"
# Extends the ancestor directive ('default-src'),
# thus reuses 'self' and adds additional sources
# Results in `img-src 'self' data: *.typo3.org`
- mode: extend
directive: 'img-src'
sources:
- 'data:'
- 'https://*.typo3.org'
# Extends the ancestor directive ('default-src'),
# thus reuses 'self' and adds additional sources
# Results in `script-src 'self' 'nonce-[random]'`
# ('nonce-proxy' is substituted when compiling the policy)
- mode: extend
directive: 'script-src'
sources:
- "'nonce-proxy'"
# Results in `worker-src blob:`
- mode: set
directive: 'worker-src'
sources:
- 'blob:'
In this csp.yaml you can now set the necessary rules for each directive of a CSP. You can choose between "extend" or "set" for each directive. With "extend" you can extend or adapt any rules already defined for a directive from the TYPO3 core or another extension. For example, the TYPO3 core already sets the necessary values for YouTube or Vimeo Video Player if these are used in the content of pages. With "set" you can completely overwrite a directive with your own definition. If you set the value "nonce-proxy" as "sources" for a directive, a nonce value is generated here for each page rendering by TYPO3 in the header of the web server. To output the same nonce value in your <script> or <style> tag in the frontend, you can either use the Fluid ViewHelper "f:security.nonce":
<script nonce="{f:security.nonce()}">const inline = 'script';</script>
Or you can integrate your JavaScripts with one of the Typoscript page.includeJS... methods. The nonce value is set automatically since TYPO3 version 12.
You can also use php to access the current nonce value in your own extension, if necessary:
// use TYPO3\CMS\Core\Domain\ConsumableString
/** @var ConsumableString|null $nonce */
$nonceAttribute = $this->request->getAttribute('nonce');
if ($nonceAttribute instanceof ConsumableString) {
$nonce = $nonceAttribute->consume();
}
Very important: All this only works if you activate the feature flag "Security: frontend enforce content security policy" in the "Feature Toggles" in the TYPO3 12 Install Tool under "Settings".
You can then check the success of your CSP with various tools. Here is an example of our website, which is already running on TYPO3 12 with CSP. We have also set a few other security headers in addition to the CSP:
https://securityheaders.com/?q=https%3A%2F%2Fwww.aemka.de%2F&followRedirects=on
Would you also like to secure your TYPO3 website with a CSP?
Get a quote!
