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.
The same-origin policy is an important security feature of any modern browser. Its purpose is to restrict cross-origin interactions between documents, scripts, or media files from one origin to a web page with a different origin. The HTTP protocol was extremely simple when it was first created.
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.
In particular, CSP is recommended for applications which manage sensitive data such as administrative UIs and device management consoles, or products hosting user-generated documents, messages or media files.
A primary goal of CSP is to mitigate and report XSS attacks. XSS attacks exploit the browser's trust in the content received from the server. Malicious scripts are executed by the victim's browser because the browser trusts the source of the content, even when it's not coming from where it seems to be coming from.
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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With