Content Security Policy (CSP) Explained

With the rapid evolution of cybersecurity threats, relying on a single layer of defense is no longer sufficient to safeguard your online presence. This makes it imperative for website owners to have a multi-layered security approach, which is best represented by the concept of defense in depth.

In websites and web applications, defense in depth can be implemented by using HTTP security response headers, specifically designed to enforce additional security controls on the client side. HTTP response headers are an important second line of defense against cyber attacks targeting web applications.

As one of the key HTTP security response headers, Content Security Policy (CSP) can effectively protect your website and its visitors from the devastating consequences of cross-site scripting (XSS) and data injection attacks.

In this guide, you will learn why Content Security Policy is a key HTTP security header and how to implement defense in depth on your site to successfully mitigate a wide range of sophisticated cyber attacks targeting WordPress.

What are HTTP Response Headers?

HTTP response headers are a set of controls implemented in websites and web applications that define how the browser interacts with the requested content. Implementing HTTP response headers can help website owners considerably improve user experience, as well as improve the functionality, performance, and security of their websites.

As small bits of information are sent along with the content requested by website visitors, HTTP response headers modify how browsers interpret and process the response received from the web server. And while the content and functionality of the website remain unchanged, implementing HTTP response headers can alter how users perceive it.

HTTP Security Response Headers as a Second Layer of Defense Against Security Threats

One of the key areas HTTP response headers, such as Content Security Policy, are used in is website security. The powerful functionality HTTP response headers provide makes them an important second line of defense against many cyber attacks targeting dynamic web applications like WordPress.

The first line of defense against cyber attacks consists of a number of code-based and server-side security measures that reduce the attack surface and eliminate application-level vulnerabilities. This includes using secure coding practices, establishing strong access control policies, and implementing a web application firewall to inspect incoming requests and filter out malicious traffic.

And while having a strong first line of defense is absolutely essential, relying on a single layer of security can still leave your website vulnerable to increasingly sophisticated attacks. A single security control can be easily circumvented, especially if an attacker is able to identify and exploit a vulnerability left unpatched.

Content Security Policy and other security response headers provide an additional layer of protection by reducing the harm malicious attacks inflict. If a malicious hacker is able to identify a vulnerability on your website successfully, a strong second line of defense will make it much more difficult for the attacker to exploit it.

What is Content Security Policy?

Content Security Policy (CSP) is a security mechanism used to define a list of trusted sources for content that a website or a specific web page is allowed to load, as well as what protocol will be used for that. This can include scripts, stylesheets, images, and other types of content that can be embedded into a web page.

Content Security Policy is a powerful defense in depth security control that helps block unauthorized requests for content located outside of the current website. In addition to this, CSP successfully prevents the execution of inline scripts and restricts unsafe dynamic code execution.

As an HTTP security response header, CSP passes the instructions configured by the website owner to the visitor’s browser. The browser, then, must follow the instructions and block the delivery of content that was not authorized by the Content Security Policy rules. This way, the browser will see that certain content was referenced by a web page but will refuse to load it.

Why is Content Security Policy so Important?

As a second line of defense, Content Security Policy does not prevent the attacker from compromising a website in most cases. Still, it will help mitigate the devastating consequences of the malware infection, blocking the hacker’s attempts to exploit it.

Even if malware is injected into your website with the purpose of stealing sensitive information or performing other malicious activities, a robust CSP policy will keep you and your customers safe. The malicious actor simply won’t be able to exploit your customers’ trust in your website, as the browser will block any malicious code from being executed in the first place.

The ability to negate hackers’ efforts to exploit your website while you regain full control over it and perform a malware cleanup after it has been compromised is what makes implementing Content Security Policy a powerful tool for securing modern websites and web applications.

What does CSP Protect From?

Content Security Policy protects a website, and its visitors from a range of cyber attacks facilitated by malware infections, as well as intrusion attempts relying on malicious scripts hosted on the resources controlled by the attacker. This includes cross-site scripting (XSS), file inclusion attacks, and clickjacking as the top three attack vectors mitigated by Content Security Policy.

Cross-site Scripting (XSS)

Cross-site scripting (XSS) is an injection attack involving inserting malicious code into a web page. The code will then be executed by the browser when the web page is loaded, allowing the attacker to steal sensitive information, hijack user sessions, or distribute malware.

To carry out cross-site scripting attacks, hackers can inject malware as an inline script, which gets embedded into HTML, or by referencing an external script, typically hosted on a website controlled by the attacker. During the process of content rendering, the malicious code will be loaded into the user’s browser and executed without their knowledge or consent.

One good example of cross-site scripting attacks affecting WordPress site owners is injecting card skimming malware into the WooCommerce checkout, which will steal the purchaser’s payment information. Card skimmers and other types of JavaScript sniffers used to carry out cross-site scripting attacks will typically look like this in the source code of a web page:

<script type="text/javascript" src="https://hackerswebsite/evil.js"></script>

In the case of an inline script, you will see malicious code embedded into the script tags or even disguised as a stylesheet by using the style tags.

The mitigation of cross-site scripting is the primary goal of implementing the Content Security Policy. By preventing the execution of inline scripts, unsafe Javascript injected using the eval function, and blocking scripts loaded from untrusted sources, Content Security Policy (CSP) effectively mitigates the risk of arbitrary code execution on a website.

File Inclusion Attacks

File inclusion attacks are another type of injection attack that Content Security Policy can mitigate. As an intrusion technique, remote file inclusion attacks allow the hacker to exploit poor input validation in different website areas to execute malicious code hosted on an external resource.

Remote file inclusion attacks often exploit unpatched vulnerabilities in WordPress plugins and themes with the purpose of breaking into a website by installing a web shell backdoor. Similar to cross-site scripting mitigation, Content Security Policy will effectively block all suspicious external scripts from being injected into the website, thus making it almost impossible for the attacker to exploit remote file inclusion (RFI) vulnerabilities.

Clickjacking

Aside from allowing website owners to define a list of trusted resources to load content from, Content Security Policy can help limit the list of websites authorized to embed content from the website within frames. This helps mitigate user interface (UI) redressing attacks such as clickjacking, which your customers can fall victim to by opening suspicious links sent to them in a spear phishing attack.

The Content Security Policy frame-ancestors directive has successfully replaced the X-Frame-Options header, which has now been deprecated by most modern browsers. This and other CSP directives are absolutely essential in WordPress security.

Content Security Policy Directives

Content Security Policy helps you specify a set of rules, known as directives, to control the sources of content that your website can load. Content Security Policy directives are a list of instructions included in the HTTP header of a requested web page that define the types of content that a browser is allowed to load on that page, along with the list of trusted sources from which it can be loaded.

Among the various Content Security Policy directives available, the rules below are the most commonly applied to secure websites from cross-site scripting (XSS), clickjacking, and data injection attacks. All of the following CSP directives, with the exception of frame-ancestors, form-action, and upgrade-insecure-requests, are fetch directives that specify the list of resources to load content from. Frame-ancestors and form-action are navigation directives that define how other resources can use the content of the website Content Security Policy is configured for.

• default-src defines the policy for loading all types of resources the browser will default to if no additional rules are specified for a certain type of content.
• script-src specifies the trusted sources of JavaScript files that can be loaded from the website.
• style-src defines the list of valid sources of stylesheets (CSS).
• img-src whitelists the resources images can be loaded from.
• media-src specifies the trusted sources of audio and video files embedded in the HTML <audio> and <video> elements
• connect-src provides control over XMLHttpRequest, EventSource, and WebSocket connections.
• child-src defines the sources of content that can be included in a web page through frames.
• frame-ancestors is a navigation directive that helps mitigate clickjacking attacks by specifying the list of resources that are allowed to embed a website’s content within frames.
• form-action restricts the resources web forms can submit information to, preventing data exfiltration to external resources controlled by the attacker.
• upgrade-insecure-requests instructs the browser to upgrade all insecure requests to HTTPS, ensuring secure connections.

Depending on the type of website and the specific functionality it provides, website owners may need to configure multiple directives to control all sources of content fetched externally.

The industry standard for ensuring sufficient protection from cross-scripting and injection attacks using Content Security Policy as the second line of defense is to limit the valid sources of external content to the current website only through the default-src directive. More targeted directives can then be used to whitelist resources for particular types of content, but denying all other resources is the recommended approach.

Configuring Content Security Policy Directives

Each Content Security Policy directive accepts a list of values represented by a Uniform Resource Locator (URL), which should include the valid web address preceded by a protocol, a domain name, a wildcard, or specific values such as 'self' or 'none' provided by the HTTP response header.

Here are some instances of values that can be assigned to Content Security Policy directives:

Directive value	Example	Definition
*	media-src*	Wildcard, used to allow all loading content from all resources.
'self'	default-src 'self' frame-ancestors 'self';	Whitelists the current website as the only valid source of specific content. Defines the strict security policy of the same origin, the recommended default Content Security Policy. Used with the frame-ancestors directive, disallows content framing on resources other than the website itself.
'none'	media-src 'none'	Disallows loading resources from any source, including the same website.
domain.com *.domain.com	img-src *.domain.com	Allows loading content from any subdomain under domain.com.
https://domain.com	default-src 'https://domain.com'	Allows fetching content only over HTTPS from the specified domain name.

By default, regardless of the rules specified, Content Security Policy will block the execution of inline scripts and prevent web pages from executing text-to-JavaScript functions such as eval, commonly used by malicious hackers. Adding the 'unsafe-inline' and 'unsafe-eval' values to the script-src Content Security Policy directive can help website owners get around the restrictions, but that can subject the website to significant security risks and undermine the protections imposed by other directives.

The following Content Security Policy header configuration effectively prevents the website from loading content from external resources and disallows the execution of inline scripts and unsafe JavaScript:

Content-Security-Policy "default-src 'self' https://mywebsite.com; frame-ancestors 'self'"

Given the 'self' value, the frame-ancestors directive mitigates clickjacking attacks by blocking content framing.

Content Security Policy and Content Delivery Networks (CDN)

As most content delivery networks, such as Cloudflare, are fully compatible with Content Security Policy and do not modify the CPS headers from the origin server. You do not need to whitelist any additional resources in the security rules you configure.

Implementing Content Security Policy for WordPress

WordPress offers various plugins for adding HTTP response headers, which can be a good option for non-technical users. While this can be a convenient option, setting up security response headers such as Content Security Policy for your WordPress website is a straightforward process that doesn’t require installing any third-party software.

The mod_headers Apache module and the ngx_http_headers_module Nginx module allow you to configure HTTP response headers for your website. If you are using Nginx, you can include the add_header directive in your website’s server {} block to configure HTTP response headers.

Similarly, If you use Apache as your web server, you can use the “Header set” and “Header append” statements to configure security policies in your website’s local .htaccess file found in the document root. This way configuration specified in the .htaccess file in your website’s root directory is applied to all web pages on the site.

It is important to note that by using Apache, you can configure HTTP response headers both locally – in an .htaccess file – and globally for all websites on the server. It’s possible that your hosting provider may configure certain response headers globally, especially if you’re on a shared hosting plan. Using the “Header set” method to configure Content Security Policy will completely overwrite the existing global rules while using “Header append” will merge your new policy onto an existing response header instead of replacing the entire configuration.

You can add the Content Security Policy configuration below to enforce strict security controls on your WordPress website

For Apache:

Header set Content-Security-Policy "default-src 'self' https://mywebsite.com; frame-ancestors ‘self’;"

For Nginx:

add_header Content-Security-Policy "default-src 'self' https://mywebsite.com; frame-ancestors ‘self’;"

Working out a Content Security Policy configuration that will meet the security needs of your website may require some testing, as well as a thorough understanding of the website’s functionality. Furthermore, implementing new security protocols on your WordPress site may potentially cause a loss of functionality, so it’s important to consider the impact of any changes carefully. You can reach out to your hosting provider or contact your developer to ensure that the security headers are properly configured and won’t be causing any negative consequences.

Implement Defense in Depth with Solid Security Pro

In today’s threat landscape, adopting a defense in-depth strategy is critical. Regarding modern dynamic web applications like WordPress, the Content Security Policy header is at the heart of defense in depth, providing a critical layer of protection against cross-site scripting (XSS), file inclusion attacks, clickjacking, and other web-based attacks.

Implementing a comprehensive defense-in-depth solution has always been challenging. But with Solid Security Pro, a robust and reliable security plugin, you can safeguard your WordPress website. With features like file integrity monitoring, vulnerability scanning, automatic software updates, and passwordless authentication, you can rest assured that all the critical parts of your WordPress website are protected from ever-evolving security threats.