What is the difference between CORS and CSPs?

SecurityWebCross Site

Security Problem Overview


From my perspective, the technologies referred to as Cross-Origin Resource Sharing (CORS) and Content Security Policies (CSPs) seem to be very similar in purpose and implementation.

Both seem to allow you to whitelist the origins of resources which an uncompromised version of your webpage incorporates, via HTTP response headers. The only difference I can see is that CSPs seem to be more fine-grained in what you can approve in your HTTP response.

Security Solutions


Solution 1 - Security

CORS allows the Same Origin Policy to be relaxed for a domain.

e.g. normally if the user logs into both example.com and example.org, the Same Origin Policy prevents example.com from making an AJAX request to example.org/current_user/full_user_details and gaining access to the response.

This is the default policy of the web and prevents the user's data from being leaked when logged into multiple sites at the same time.

Now with CORS, example.org could set a policy to say it will allow the origin https://example.com to read responses made by AJAX. This would be done if both example.com and example.org are ran by the same company and data sharing between the origins is to be allowed in the user's browser. It only affects the client-side of things, not the server-side.

CSPs on the other hand set a policy of what content can run on the current site. For example, if JavaScript can be executed inline, or which domains .js files can be loaded from. This can be beneficial to act as another line of defence against XSS attacks, where the attacker will try and inject script into the HTML page. Normally output would be encoded, however say the developer had forgotten only on one output field. Because the policy is preventing in-line script from executing, the attack is thwarted.

Solution 2 - Security

CORS allows a site A to give permission to site B to read (potentially private) data from site A (using the visitor's browser and credentials).

CSP allows a site to prevent itself from loading (potentially malicious) content from unexpected sources (e.g. as a defence against XSS).

Solution 3 - Security

Update: @JodySowald's comment, which I find more succinct:

> Content-Security-Policy prevents calls to external resources and Cross-Origin-Resource-Sharing prevents calls from external sources. To provide an example. For abc.com to show def.net in an iframe, abc.com must not block def.net with its CSP settings and def.net must not block abc.com with its CORS settings.


Original answer:

None of the answers above give a clear and concise difference between CSP and CORS. Here is my way of thinking about them:

Let's say we have abc.com website that wants to send a request to def.net.

  1. When user visits abc.com in browser, abc.com server returns abc.com HTTP response, CSP restriction within this response can prevent abc.com in browser from issuing request to def.net.
  2. If there is no CSP restriction within abc.com HTTP response, then abc.com in browser can send a request to def.net.
  3. Upon receiving the request, def.net server responds with def.net HTTP response, CORS restriction within this response can prevent abc.com in browser from loading it. (Note that by default, Same-origin policy will restrict the response from loading, unless otherwise specified by CORS)

So CSP protects abc.com and same-origin policy (the lack of CORS) protects def.net in the example above.

Solution 4 - Security

CORS checks with the third party for authorization to use its services. So, the third party provides or denies authorization.

So for example if a page in www.example.com needs to make a request to www.example.org we need to send an OPTIONS request sent to www.example.org with Origin:www.example.com as a precursor to request for authorization. Now, www.example.org provides or denies authorization.

CSP prevents a webpage from inadvertently loading malicious content from a third party by specifying where a particular type of content can be loaded from. So, for example you can provide a valid source for each of the following scripts, css, media etc. by using directives

Example:

Content-Security-Policy: default-src 'none'; script-src 'self' www.google-analytics.com ajax.googleapis.com; connect-src 'self'; img-src 'self'; style-src 'self';

Attributions

All content for this solution is sourced from the original question on Stackoverflow.

The content on this page is licensed under the Attribution-ShareAlike 4.0 International (CC BY-SA 4.0) license.

Content TypeOriginal AuthorOriginal Content on Stackoverflow
QuestionnickformView Question on Stackoverflow
Solution 1 - SecuritySilverlightFoxView Answer on Stackoverflow
Solution 2 - SecurityQuentinView Answer on Stackoverflow
Solution 3 - SecurityparaditeView Answer on Stackoverflow
Solution 4 - Securitysbdh shvpjView Answer on Stackoverflow