Difference between CORS and CSP Security Headers

Cross Origin Resource Sharing(CORS) and Content Security Policy(CSP) are HTTP response headers which when implemented help to improve the security of a web application. Both security headers allow application owners to whitelist the origin of resources in their web application. Both Security headers seem to work in a similar fashion but they actually do not.

To explain the CORS header, first we need to understand SameOriginPolicy. Let’s consider two domains

  1. xyzapp.com
  2. abcapp.com

If xyzapp.com wants to access details from abcapp.com/userinfo. SameOriginPolicy prevents xyzapp.com from making an AJAX request to abcapp.com/userinfo and get the response. SameOriginPolicy is the default policy followed in all browsers which prevents data sharing between two different domains.

CORS provides relaxation to SameOriginPolicy which enables data sharing between two domains in a secure way if it is configured properly. CORS can set a policy to allow xyzapp.com to access details from abcapp.com/userinfo by setting CORS Header in abcapp.com application as

Access-Control-Allow-Origin: ‘xyzapp.com’

By setting this header xyzapp.com can send an Ajax request to abcapp.com/userinfo and its response can be loaded in xyzapp.com. There are some more CORS headers which define the allowed methods, allowed headers, allowed age etc., and we can see the detailed implementation of CORS headers in my next blog.

Improper configuration of CORS headers leads to security risk as I have seen in most of the web applications that CORS header is set as

Access-Control-Allow-Origin: ‘*’

or

Access-Control-Allow-Origin: ‘any’

where application is giving permission to any domain or practically all domains to access your application content. The best way to implement a CORS header is to allow only authoritative and valid domains which require access to your application.

Content Security Policy(CSP) header is used to define what content can run on its own domain. For example, abcapp.com domain wants to access a javascript library only from “userscripts.example.com” and not from any other third-party libraries then abcapp.com can set the header as

Content-Security-Policy: script-src userscripts.example.com

In this way, javascript libraries are loaded only from userscripts.example.com and not from any other domains where it mitigates the risk of malicious third-party scripts or content being executed in our domain abcapp.com. In the above example ‘script-src’ is a directive in CSP. Likewise, there are many CSP directives where we can define the image source, style source etc., and we can see the detailed explanation of CSP directives in our upcoming blog series.

In the above scenario’s abcapp.com sets CORS header to make its resources can be accessed by xyzapp.com

Access-Control-Allow-Origin: ‘xyzapp.com’

abcapp.com also sets a CSP header to access the scripts loaded and executed only from ‘userscripts.example.com’ and not from any other domain which defines what content can run on its own domain

Content-Security-Policy: script-src userscripts.example.com

The conclusion is CORS header makes the resources of abcapp.com can be accessed by xyzapp.com and CSP header defines the control of what content can run on its own abcapp.com

2 COMMENTS

LEAVE A REPLY

Please enter your comment!
Please enter your name here

*