Learn about Content Security Policy (CSP) , a powerful tool to protect against malicious content injections. Understand how to configure CSP for various use cases and enhance web security.
If you are doing web development, you’ve probably seen the following error message in the debug console:
This is an error that is generated by the browser. The error is because the browser supports Content Security Policy which is designed to reduce harm to users from malicious content injections attacks. Content Security Policy can significantly reduce the risk and impact of cross-site scripting attacks in modern browsers.
Content Security Policy (CSP), a tool which developers can use to lock down their applications in various ways, mitigating the risk of content injection vulnerabilities such as cross-site scripting, and reducing the privilege with which their applications execute.
- W3C Working Draft, Content Security Policy Level 3
The CSP is an added level of security that helps to identify and mitigate different types of attacks including Cross-Site Scripting (XSS) attack, and data injection attacks. Content injection attacks are very common, 50% of the known Wordpress plugin vulnerabilities are exploited by XSS. The “injection” is usually achieved by finding a way to load external resources to the page.
“Instead of blindly trusting everything that a server delivers, CSP defines the Content-Security-Policy HTTP header, which allows you to create an allowlist of sources of trusted content, and instructs the browser to only execute or render resources from those sources. Even if an attacker can find a hole through which to inject script, the script won't match the allowlist, and therefore won't be executed.”
- Mike West & Joe Medley, Web.dev CSP
The Content Security Policy Header is the mechanism to instruct the browser about which resources and sources of content should be trusted and can be loaded. The Content Security Policy Header allows developers to instruct your web-server to only restrict access to certain sources of scripts. This might include limiting scripts to only those accessed on from your domain, or may include Google Analytics and other services your web applications might be using. Under normal circumstances, the list of whitelisted URLs is very small. You can configure your web server to put a Content Security Policy Header in the response header instructing the browser.
The flexibility of the restrictions is very broad. The CSP can be defined to restrict:
CSP is configurable but instructs the browser to protect the users from harm. You lock down the sources of your content and even a successful XSS attack may not be able to “talk to the mothership”, because access is blocked.
Different platforms have different requirements. Google Analytics 4 (GA4) gets more complicated if you're also using Google Tag Manager (GTM). GTM requires specific permissions in the CSP to function correctly.
Assume that you run a health care site or a banking site and only want those resources that you’ve written to be loaded for users. For this scenario, you’d start with a restrictive policy that blocks absolutely everything (default-src ‘none’), and then begin to build from there.
The next steps are to figure out the plan for loading images, scripts, and style. Imagine that the images, scripts and styles are loaded from a CDN at https://cdn.mymedicalapp.net, and connects via XmlHttpRequest (XHR) to https://api.mymedicalapp.com to pull various bits of data. There are no plugins, no fonts, no extras used on the site. The most restrictive CSP that could be used is:
Because CSP can be enabled at the server, it makes a lot of sense for administrators and operators of self hosted web applications like forums, bulletin boards systems and other applications to ensure that all resources only loaded via secure channels. These applications may have a lot of inline script and style that is part of the legacy code.
Even though https: is specified in the default-src, the script and style directives do not automatically inherit the requirement. Each directive must be specified otherwise the default is used.
Configuring CSP as an HTTP header depends on your specific web server, load balancer combination. Ideally, you would put it into the front-line, i.e. the server/load balancer that serves your content. We will show examples for 3 common setups.
The OWASP secure header project has a list of CSP configurations for security https://wiki.owasp.org/index.php/OWASP_Secure_Headers_Project#csp that show different configurations and restrictions that can be useful for your specific web application.
Full instructions to add Security Header for Content Security policy to AWS CloudFront under CloudFront » Policies » Response Headers. Or in your webserver configurations directly.
CoGuard is a code scanner for configuration files. CoGuard discovers configurations and configuration files in your IaC code repositories, on your cloud configurations, or in your file system and the containers. CoGuard provides policies that include the identification of the Content Security Policy and other best practices in security. Find out the state of your configurations before you push them to production.
