Staying safe while using the internet is really important. The people who create websites have a big job because they need to protect us from bad things like hackers stealing our information or causing trouble. But guess what? They have a special tool called Content Security Policy, or CSP, that makes websites safer for everyone.
In this article, we’re going to take a closer look at this header. We’ll learn what it is, how it works, and why it’s so great at keeping us safe online. So, by the time you finish reading, you’ll understand why CSP is like a superhero for websites, helping to keep our information and online experiences secure.
Contents
What is Content Security Policy (CSP)?
When we browse the web, we interact with various websites and online services. While doing so, our actions can have an impact on our online security. This is where the CSP header comes into play.
Mozilla documentation says that “Content Security Policy (CSP) is an added layer of security that helps to detect and mitigate certain types of attacks, including Cross-Site Scripting (XSS) and data injection attacks.”
Understanding the CSP header
This header is a vital component of online security. Its main function is to help protect your website against certain types of cyberattacks, such as malicious script injection. When a browser receives a web page, it checks the CSP header provided by the server. The header contains instructions that the browser will follow to determine what resources it can load and execute on the page.
BuiltWith says that Content Security Policy is used by 90.000 of the top 1 million websites out there.
Is the CSP header a vulnerability?
No, this header is not a vulnerability in itself. Rather, it is a security measure you can implement to strengthen your website’s defense against potential vulnerabilities. If not configured properly, it could cause issues, such as blocking legitimate resources on your website, but its primary goal is to protect your site from threats.
The difference between CSP and CORS
The CSP header (Content Security Policy) and CORS (Cross-Origin Resource Sharing) are two different but related web security tools.
As mentioned earlier, CSP focuses on controlling which resources can be loaded and executed on a web page. This header helps prevent attacks like malicious script injection and ensures that resources come from trusted sources.
In contrast, CORS is responsible for allowing or restricting requests for resources from a different web domain than the origin domain. It helps prevent attacks that could exploit trust between different websites.
How to check my CSP header
If you’re a web developer or a website owner and want to check if your website has this header configured properly, you can do so easily.
- Open our web security scanner.
- Type your domain in the scan box.
- Make sure to tick the two boxes below, named ‘Clear cache’ and ‘Follow redirects’.
- Now click the Scan button.
- Scroll down to the section named ‘HTTP Security Headers’ and check the results for ‘CPS header’: a ‘Passed’ in green means your header is set properly, but if you get a ‘Failed’ in red then it’s not good and you must update your current settings.
CSP header directives
The directives are like rules that you can set for your website to control where it can load resources from. They help make your website more secure by limiting what external sources can be used in your web pages. Let’s take a look at them:
- default-src: this directive sets the default source for various types of resources. Think of it like a rules that says “By default, only load resources from the same place as the web page itself.”
- script-src: it controls where your website can load JavaScript code from. For example, you can only allow scripts to come from your own website (‘self’) or from a specific trusted domain.
- style-src: this directive determines where your website can get its styles or CSS from.
- img-src: it specifies where images can be loaded from. You can restrict it to your own site or trusted sources.
- frame-src: this one is about controlling where web pages can be loaded inside a frame or iframe. You can decide to only allow it from your site or limit it to specific places.
- font-src: it controls where your website can load fonts from. You may want to limit it to your own domain or trusted font providers.
- connect-src: this directive decides which servers your website can connect to. For example, you can allow connections to your own server or other trusted services.
- object-src: it restricts where plugins or embedded objects can be loaded from. You can choose to allow them only from trusted sources or none at all.
- child-src: this is used to specify the sources for child browsing contexts like iframes and workers.
- media-src: it controls where media elements like audio or video can be loaded from.
- frame-ancestors: this directive is used to determine which sites are allowed to embed your website in a frame. It helps prevent clickjacking attacks.
- manifest-src: this directive specifies where the web application manifest file can be loaded from.
CSP header examples
Let’s see a few CSP header examples that may be used in some common situations.
Basic default header: the most basic CSP header, which allows resources only from the same origin, it is an excellent initial configuration for many websites:
Content-Security-Policy: default-src 'self';
Allowing specific sources: to include trusted external sources, tailor your CSP header accordingly. In this instance, it permits scripts from your origin and a specific trusted domain:
Content-Security-Policy: script-src 'self' trusted-scripts.com;
Nonce-based policies: to enhance security, employ nonces, which are unique values generated for each request. This strategy thwarts attackers attempting to inject malicious code:
Content-Security-Policy: script-src 'self' 'nonce-abc123';
Report-only mode: to test your policy without actually enforcing it and gather violation reports through the report-uri directive, use the following configuration:
Content-Security-Policy-Report-Only: default-src 'self'; report-uri /csp-report-endpoint;
Allowing Multiple Trusted Sources: for websites relying on multiple external sources, it’s possible to grant access to several trusted domains. In this example, scripts from your domain, a trusted Content Delivery Network (CDN), and a partner site are allowed:
Content-Security-Policy: script-src 'self' cdn.example.com partner-site.com;
Limiting inline scripts and styles: inline scripts and styles can pose security risks. To confine them to a trusted set of elements using nonces, employ the following CSP configuration:
Content-Security-Policy: script-src 'self' 'nonce-abc123' 'nonce-def456'; style-src 'self' 'nonce-ghi789';
Enforcing strict policies: for a very high level of security, implement an extremely strict CSP policy that exclusively permits resources from your domain and disallows inline scripts:
Content-Security-Policy: default-src 'self'; script-src 'self'; object-src 'none'; style-src 'self'; img-src 'self'; media-src 'self'; frame-src 'none'; font-src 'self'; connect-src 'self';
How to configure a CSP header
Let’s see how to configure CSP headers in Apache, Nginx, and IIS, and let’s also look at the special headers required for CloudFlare products.
Enabling the CSP headers in Apache
Open the Apache configuration file, which may be located at various paths such as /etc/httpd/httpd.conf or /etc/apache2/apache2.conf, depending on your Linux distro and installation settings. Alternatively, you can use a .htaccess file for specific directories.
To establish the header in Apache, utilize the Header directive within a <VirtualHost> block or directly within a .htaccess file. For example, to create a basic policy allowing content from the same origin and a specific domain for scripts, use this configuration:
Header set Content-Security-Policy "default-src 'self' trusted-scripts.com;"
Remember, this is just an example, you have to set your own header according to your site’s needs. Also, don’t forget to enable the headers mod if it isn’t enabled.
a2enmod headers
Now restart Apache:
systemctl restart apache2
Setting up the CSP headers in Nginx
Open your Nginx site configuration file, most of the time it can be found in /etc/nginx/sites-available/ or /etc/nginx/conf.d/
Within a server block or a specific location block, use the add_header directive to define the CSP header. For instance:
add_header Content-Security-Policy "default-src 'self' trusted-scripts.com;";
Test if your config syntax is correct:
nginx -t
If the result is ok then go ahead and restart Nginx:
systemctl restart nginx
Configuring the CSP headers in IIS
Launch the IIS Manager on your Windows server and select your site in the left panel.
Double-click “HTTP Response Headers”, then click “Add…” on the right side to create a new custom HTTP response header.
Set the name as “Content-Security-Policy” and define the value as your CSP policy, for example:
default-src 'self' trusted-scripts.com;
Click “OK” to save your new header.
You may need to restart the IIS server for the changes to take effect.
Enabling the CSP headers in CloudFlare
CSP headers can’t be set on CloudFlare’s end, instead, they are set on your web server. However, some CloudFlare products require that you update your headers to work as expected.
You can find this information on CloudFlare’s page.
CSP Header FAQ
What does CSP mean?
It stands for “Content Security Policy.” It’s a web security feature that helps prevent attacks like malicious code injection and session hijacking. Simply put, it’s a set of rules that a website uses to stay safe from harmful things. Think of it as a security guard for your website. It controls who can and can’t access your site, preventing bad guys from causing trouble.
Is CSP necessary?
While it’s not absolutely necessary, using this header is highly recommended to improve your website’s security. It helps mitigate threats like Cross-Site Scripting (XSS) by limiting the allowed sources of content on a web page. Properly using CSP can protect users and reduce security risks on your site.
Summary
The CSP header, or Content Security Policy header, is an integral part of online security. It shields websites from cyberattacks, such as malicious script injection, by instructing web browsers on resource loading and execution.
CSP differs from Cross-Origin Resource Sharing (CORS), as it primarily focuses on resource control rather than inter-domain requests. If you’re a web developer or a site owner, you can examine your CSP headers using your browser’s developer tools, or you can use online tools.