Content Security Policy (CSP): what is it?

content security policy (csp)


content security policy (csp)

It uses meta elements or headers to greenlight or block the content loaded on your website. CSP (Content Security Policy) provides an extra layer of protection and is widely recommended for all website administrators.

Discover, in this article, CSP and why it is so important.

Content Security Policy (CSP), kezako?

A Content Security Policy (CSP) or content security strategy aims to improve the security of websites.

To do this, it detects and reduces a certain number of attacks, including attacks Cross-Site Scripting (XSS) and code injections. These attacks are generally aimed at distributing malware, site defacing or data theft.

The CSP is an HTTP header returned by the web server to indicate to users’ browsers the sources authorized to load content on the visited site.

For example, if you use an external service to embed particular fonts, you can tell users’ browsers which servers are allowed to:

  • loading font files on your site,
  • and servers that are not.

The first specification of the CSP dates from February 2015. It was then updated in December 2016 and continues to evolve.

Why is a content security strategy important?

A Content Security Policy adds a second layer of protection against various attacks. It thus protects the user and the website both for:

Reduce or mitigate cross-site scripting

The main benefit of defining a Content Security Policy (CSP) is to detect and mitigate XSS attacks.

These attacks exploit the web browser’s trust in the content provided by the server to force it to execute malicious scripts.

The injected malicious code retrieves all user input:

  • personal data,
  • identifiers,
  • Passwords…
See also  Google will be rolling out a Product Review Update at the end of August / beginning of September!

The attacker thus accesses the user’s data and bypasses the authentication. It can even compromise the account and keep permanent access.

💡All this happens without the user suspecting anything.

In reality, XSS are ubiquitous and one of the most common flaws in web applications.

This type of vulnerability accounts for more than 60% of payments under Google’s Vulnerability Reward Program. Google blocks your site when it identifies malicious code, thereby blocking your customers’ access.

With a strict CSP, server administrators can reduce or eliminate the possibility of exploiting an XSS flaw.

To do this, they must define the Internet domains that client browsers must trust for the execution of scripts.

Browsers compatible with CSP therefore only execute scripts from domains present on the defined whitelist. However, they ignore all other scripts including HTML event handling attributes.

Limit or prevent traffic eavesdropping

In addition to restricting trusted domains, servers can also specify which protocols to use.

For example, they can force the use of HTTPS for loading content to improve the security of web applications.

A complete Content Security Policy involves implementing the HTTPS protocol in data transfer. It also involves:

  • mark all cookies with the secure attribute,
  • and set up automatic redirects from HTTP to HTTPS pages.

Additionally, sites can use HTTPS Strict-Transport-Security headers to ensure that users’ browsers connect to the site only through TLS-encrypted channels.

When to use a CSP?

The vast majority of complex web applications have a high vulnerability to XSS and would benefit from using CSP.

The use of a CSP is particularly recommended for applications that manage sensitive data such as:

  • device management consoles,
  • administration user interfaces,
  • or any other product that hosts user-created files or messages.

In modern frameworks (closure models), the use of CSP is relatively simple and generates a significant return on investment in terms of additional security.

When to use other security mechanisms?

CSP is an additional security mechanism for secure applications with no known vulnerabilities.

See also  95% of iCloud users have this layer of security enabled

However, in some cases, adopting a content security policy may not be the best choice. It would then be better to focus on other solutions with a greater impact on security:

Static applications – Web applications without cookies or login functionality and hosted on their own domains or subdomains have low vulnerability to XSS.

Large applications that have fallen victim to XSS in the past or have known flaws in the frameworks or models they use. A CSP alone will not provide sufficient protection in these cases. So the best solution is to fix the vulnerable code or invest in patches.

How to configure a CSP rule?

Setting up a Content Security Policy (CSP) requires using a Content-Security-Policy HTTP header. Here is a three-step procedure to do so:

1 – Define your CSP rule

The first step is to define the policies or guidelines along with the source values ​​indicating the resources to be allowed or restricted.

Among the most common directives we have:

default-src: defines the default policy used in all cases (fonts, CSS, JavaScript, Frames, etc.) when set to ‘self’.

Script-src: defines the authorized script sources

Style-src: defines the sources of style sheets (CSS) allowed

Object-src: defines allowed plugin sources (ex: or )

img-src: defines authorized image or icon sources (ex: rel=”icon”)

media-src: defines the sources of authorized multimedia elements (ex:

frame-src: defines the authorized sources for loading frames (frame or iframe)

font-src: defines authorized sources for loading font files

connect-src: apply CSP to connections from an XMLHttpRequest (AJAX) or a WebSocket

bade-uri: allow URLs in the src attribute of any tag

report-uri or Content-Security-Policy-Report-Only: Receive reports without applying content security policy.

Add-header: add header for Content Security Policy

2 – Test your CSP rule

You can test your CSP to be sure that you have included the necessary trusted domain origins for your site.

In particular, you can:

  • use the HTTP Response header on Content-Security-Policy-Report-Only to receive alerts for violations of your Content Security Policy without the rule being applied,
  • configure the report-uri directive with a URL where you will receive CSP violation reports.
See also  Cookies and GDPR: how to ensure compliance?

3 – Implement the Content Security Policy

There are two main configurations for applying your CSP rule.

The first, less popular option works on all browsers. The second, on the other hand, requires defining the HTTP response header.

1 The Meta Tags configuration

It is possible to activate your CSP in the HTML code of the page using the HTML tag.

For this, you need to set the tag in the to make the rule apply as soon as possible. It looks like this:

<meta http-equiv="Content-Security-Policy"

content=”default-src ‘auto’; img-src *”>

2 The CSP http response header configuration

This is the most appropriate way to implement a CSP by w3; it works on most browsers.

Here, we will use Content-Security-Policy without the Report-Only element. Note that most of the rules applied to your response header will occur in your server’s configuration file.

To do this, you need to identify the server your website is running on and set your response header.

IIS (Internet Information Services)

  • Go to your IIS manager and select your website on the left
  • Select the HTTP Response Headers icon
  • Click “add” and enter the header name and value.

You can also add your content security policy directly to the web.config file. According to your guidelines, it will look like this:

Learn more about modifying HTTP response headers.

Nginx

You can modify the response header by adding a directive [add_header] in the corresponding configuration files in the server blocks. According to your rules, it will look like this:

add_header Content-Security-Policy’ default-src ‘self’; img-src*”

apache

On an apache server, you must define the Content Security Policy in your site’s .htaccess file or in VirtualHost or httpd.conf.

It will look like this according to your guidelines:

Header set Content-Security-Policy-Report-Only “default-src ‘self’; img-src*”

Above all, don’t forget to remove the Report-Only element after the test phase.

Leave a Comment

Your email address will not be published.