Web pages you visit make frequent requests to load assets like images, fonts, and more, from many different places across the Internet. If these requests for assets go unchecked, the security of your browser may be at risk. For example, your browser may be subject to hijacking, or your browser might blindly download malicious code. As a result, many modern browsers follow CORS security policies to mitigate such risks.
WHAT IS CORS?
As stated in Wikipedia: https://en.wikipedia.org/wiki/Cross-origin_resource_sharing
Cross-origin resource sharing (CORS) is a mechanism that allows restricted resources on a web page to be requested from another domain outside the domain from which the first resource was served.
A web page may freely embed cross-origin images, stylesheets, scripts, iframes, and videos. Certain “cross-domain” requests, notably Ajax requests, are forbidden by default by the same-origin security policy. CORS defines a way in which a browser and server can interact to determine whether it is safe to allow the cross-origin request. It allows for more freedom and functionality than purely same-origin requests but is more secure than simply allowing all cross-origin requests.
The “same-origin” policy in CORS is very restrictive. Under this policy, a document (i.e., like a web page) hosted on server A can only interact with other documents that are also on server A. In short, the same-origin policy enforces that documents that interact with each other have the same origin.
Using those CORS headers allow web developers to restrict what external sources can be shown, downloaded or embedded on their website. Thus, extending the protection against code injection and so on. There are different headers/policies each targeted to a particular resource.
Currently, you may use the following CORS headers:
Content Security Policy
The CSP CORS header allows you to define a whitelist of approved sources of content for your site. By restricting the assets that a browser can load for your site, like js and CSS, CSP can act as an effective countermeasure to XSS attacks.
HTTP Strict Transport Security
Sites have always heavily relied on a 301/302 redirect to take users from browsing over HTTP to HTTPS. With browsers defaulting to HTTP when you type in an address, this has previously been the only way. HSTS allows you to tell a browser that you always want a user to connect using HTTPS instead of HTTP. This means any bookmarks, links or addresses the user types will be forced to use HTTPS, even if they specify HTTP. This policy will enforce TLS on your site and all subdomains for a year.
HSTS allows for more effective implementation of TLS by ensuring all communication takes place over a secure transport layer on the client-side. Most notably HSTS mitigates variants of man in the middle (MiTM) attacks where TLS can be stripped out of communications with a server, leaving a user vulnerable to further risk.
HTTP Public Key Pinning
The great thing about SSL/TLS certificates is that you can buy a certificate from any trusted Certificate Authority and the browser will happily accept it. The problem with this is that when a Certificate Authority is compromised, an attacker can issue themselves an SSL/TLS certificate for your site and the browser will accept this rogue certificate as it came from a trusted Certificate Authority. HPKP allows you to protect yourself by providing a whitelist of cryptographic identities that the browser should trust. Whilst HSTS says the browser must always use HTTPS, HPKP says the browser should only ever accept a specific set of certificates. Read more on my blog about HTTP Public Key Pinning.
The X-Frame-Options CORS header (RFC), or XFO header, protects your visitors against clickjacking attacks. An attacker can load up an iframe on their site and set your site as the source, it’s quite easy: Using some crafty CSS they can hide your site in the background and create some genuine looking overlays. When your visitors click on what they think is a harmless link, they’re actually clicking on links on your website in the background. That might not seem so bad until we realise that the browser will execute those requests in the context of the user, which could include them being logged in and authenticated to your site!
This CORS header is used to configure the built-in reflective XSS protection found in Internet Explorer, Chrome and Safari (Webkit). Valid settings for the header are 0, which disables the protection, 1 which enables the protection and 1; mode=block which tells the browser to block the response if it detects an attack rather than sanitising the script.
Nice and easy to configure, this CORS header only has one valid value, nosniff. It prevents Google Chrome and Internet Explorer from trying to mime-sniff the content-type of a response away from the one being declared by the server. It reduces exposure to drive-by downloads and the risks of user-uploaded content that, with clever naming, could be treated as a different content type, like an executable.
Feature Policy is being created to allow site owners to enable and disable certain web platform features on their own pages and those they embed. Being able to restrict the features your site can use is really nice but being able to restrict features that sites you embed can use is even better protection to have.
This is a new header that allows a site to control how much information the browser includes navigations away from a document and should be set by all sites.
Referrer-Policy will allow a site to control the value of the referer header in links away from their pages. When a user clicks a link on one site, the origin, that takes them to another site, the destination, the destination site receives information about the origin the user came from. This is how we get metrics like those provided by Google Analytics on where our traffic came from. You can know, for example, how many users came from Twitter this week because when they visit your site they set the referer header in their request.
This referer CORS header lets you know where the inbound visitor came from and is really handy, but there are cases where you may want to control or restrict the amount of information present in this header like the path or even whether the header is sent at all.