CSP and CORS
The nightmare of every front-end developer is errors related to CORS and CSP while trying to load web resources from a different origin. Well, let’s understand what different origin actually means.
Origin usually means the protocol, domain, and port number. If all three components are the same, it is referred to as “same-origin”.
An interesting thing to note here is that https://example.com and http://example.com would be considered as different origins due to difference in the protocol.
CSP
Now that we are clear what same-origin and cross-origin mean, it should be easier to understand what CSP means.
CSP(Content Security Policy) is a set of directives that can be enforced on a page in order to restrict the resources being loaded onto the said page.
But why do we need this ability? Why shouldn’t we be allowed to load anything from anywhere? I think everyone might have heard that it’s needed for “security reasons”. But what does that exactly mean?
First of all, to whom does it provide security? It provides security to the web page it has been enforced on. CSP prevents your site from attacks such as XSS(Cross-site scripting). Cross-site scripting involves injecting an external script into a webpage in order to perform some malicious activity.
Suppose you have an input form on your site, the hacker can submit a javascript code snippet as an input. In case the input form doesn’t have appropriate validation in place, the browser assumes this to be javascript code and executes this code snippet. Suppose the form input is saved in the database and rendered every time someone opens this site, the script gets executed for all users who hit this page. This opens up opportunities for the hacker who can then use the javascript code snippet in order to get the cookie information of other users and send it to another server which can later be used by the attacker to gain access to the accounts of the compromised users.
So how does CSP help in this scenario? Suppose you have prohibited inline-scripting through CSP it won’t be possible for the attacker to inject this code snippet through form input.
Now the question arises, why do we need CSP for this? Why couldn’t this be handled as a part of form input validation? Yes precisely, form input validation is the first line of security. CSP just forms a fallback mechanism to prevent such attacks. Security by CSP will be triggered if all else fails. If there’s somehow a hole in the system which the attacker exploits in order to inject the malicious script, CSP will the last line of defense to prevent such attacks.
I hope by now it’s clear, what’s CSP and why exactly it’s needed. Let’s talk about how to use it and how does it work? There are two ways to add CSP directives to your page as listed below.
Meta tags
HTML meta tag with an http-equiv attribute can be added to each page. Example below
<meta http-equiv="Content-Security-Policy" content="default-src https://cdn.example.net; child-src 'none'; object-src 'none'">HTTP Headers
CSP directives can also be configured through HTTP headers of the response page. This needs to configured at the server level.
Content-Security-Policy: default-src https://cdn.example.net; child-src 'none'; object-src 'none'The exact way to configure the CSP might vary depending on the server being used (apache, windows IIS, etc).
Either of the two ways can be used in order to set the CSP directives. There might be a few differences between the two. A few directives are available only through headers.
CORS
CORS refers to Cross-Origin Resource Sharing. Our internet is based on the same-origin policy, so if your site(abc.com) needs to load some kind of resource(image, JSON, etc) from xyz.com it becomes an issue because ideally, we don’t want any site to load a resource from any other site. But that doesn’t mean we won’t encounter scenarios where this is needed. There are a few ways to get around this. But if you are the site that’s serving the resource(xyz.com) and you want a few or all sites to have access to use the resources being hosted here, there’s a way you can make this happen through CORS.
I hope by now, it’s clear why CORS is needed. But what’s CORS? It’s a way to tell the browser that it’s fine if this particular site accesses resources from my site through HTTP headers. Specified below are the headers related to CORS-
1. Access-Control-Allow-Origin
2. Access-Control-Expose-Headers
3. Access-Control-Max-Age
4. Access-Control-Allow-Credentials
5. Access-Control-Allow-Headers
The main one among these to depict how CORS can be used is Access-Control-Allow-Origin. Using this header, it’s possible to specify certain domains which can access a particular resource from your domain. These headers can be added at the server level or even at the controller level.
Example
Access-Control-Allow-Origin: *
The above header specifies that this particular resource/API endpoint can be accessed from any origin.
Access-Control-Allow-Origin: https://foo.example
The above header can be used to allow access to the endpoint only from a specific domain, in this case, https://foo.example.
CONCLUSION
I hope by now you have understood the need for CSP and CORS and have a conceptual idea about them. This is just an introductory article, please find more references below to dig deeper.
CORS, Documentation by Mozilla
CSP, Documentation by Mozilla
CSP, Interesting introduction by Google Developers