↓ Skip to main content
Antomor
  1. Blog/

CSP and CORS

·527 words·3 mins
Antonio Morrone
Author
Antonio Morrone
Staff/Tech Lead Software Engineer. Building software since 2013, in blockchain protocols & Web3 infrastructure since 2021. Security-minded. Remote from Italy.
Table of Contents

What is CSP
#

CSP stands for Content Security Policy and it is a security mechanism that helps to protect or mitigate some common attacks such as XSS (Cross-site scripting). It can be set by means of a Content-Security-Policy HTTP header or using an HTML meta tag.

HTTP header:

Content-Security-Policy: policy

HTML Meta tag:

<meta http-equiv="Content-Security-Policy" content="policy">

A policy describes a set of directives, each composed of the area in which the rule is applied and the rule itself. The policy directive default-src 'self' says to load all content from the site’s origin, while if we want to load content from the site and from another trusted domain, the policy would be Content-Security-Policy: default-src 'self' *.trusted.com.

What is CORS
#

CORS stands for Cross-Origin Resource Sharing and it is a mechanism that permits a web application running at an origin to access resources served from a different origin. What is an origin? The origin is identified by domain, protocol and port. It uses a set of HTTP headers to declare which domains are entitled to access the resource. Let’s have a look at the following scenario:

  1. We have a web application running on domain-a.com
  2. We have a web service running on domain-b.com
  3. domain-a.com web app wants to access the service published on domain-b.com

The service on domain-b.com should enable CORS by properly setting HTTP Headers. The headers involved in CORS are:

  • Access-Control-Allow-Origin - Origin can load the resource
  • Access-Control-Allow-Methods - Methods can be used to access the resource
  • Access-Control-Allow-Headers - Request headers allowed
  • Access-Control-Max-Age - Value in seconds describing for how long the pre-flight response is cached (wait, pre-what?)

Pre-flight request
#

When the browser encounters a cross-domain request, it performs a so-called pre-flight request. In practice it performs an HTTP request using the OPTIONS method to verify if CORS is enabled. If and only if the response is successful (response code 204 - No Content) and the previously mentioned HTTP headers are properly set, the browser will send the real request.

Relation
#

So, what is the relation between CSP and CORS?

Let’s have a look at the previous scenario again.

  1. We have a web application running on domain-a.com
  2. We have a web service running on domain-b.com
  3. domain-a.com web app wants to access the service published on domain-b.com

As we have previously said, the web service exposed on domain-b.com must enable CORS, but that might not be enough. If we have configured CSP on the domain-a.com web application, we also need to relax the connect-src policy directive to allow https://domain-b.com. So, to properly run the previous scenario:

  1. Enable CSP on domain-a.com
  2. Enable CORS on domain-b.com, by allowing domain-a.com using the Access-Control-Allow-Origin header.
  3. Relax the CSP (header or HTML tag), by setting the connect-src policy directive to allow the domain-b.com connection.

Very important notes
#

  • Please, setting CSP to be able to connect to everything (*) is a BAD CSP configuration, unless you know what you are doing.
  • Please, setting CORS to return always the Access-Control-Allow-Origin header set with * is a BAD CORS configuration, unless you know what you are doing.

Resources
#