Introduction to CORS-Cross-origin resource sharing & SOP-Same Origin Policy, CORS series (Part 1)

CORS (Cross-Origin Resource Sharing) is a security mechanism used by web browsers to control and allow specific types of cross-origin requests. It helps bypass the restrictive Same-Origin Policy (SOP) but in a controlled manner.

Example — Imagine a scenario where:

A web application hosted at https://example.com wants to fetch data from a REST API hosted at https://api.someotherdomain.com.Due to SOP, the browser will block this request because the two URLs have different origins.

But with CORS:

The server at https://api.someotherdomain.com can include specific HTTP headers (like Access-Control-Allow-Origin) to tell the browser which domains are allowed to access its resources.If the headers are present and configured to permit https://example.com, the browser allows the request to proceed.

This means that in one place where SOP does not allow any interaction between different origin requests, CORS does allow that interaction but in a controlled manner.

The same-origin policy is a restrictive cross-origin specification that completely limits the ability for a website to interact with resources outside of the same origin.

The same-origin policy restricts scripts on one origin from accessing data from another origin. An origin consists of a URI scheme, domain and port number. For example, consider the following URL:

http://normal-website.com/example/example.html

This uses the scheme http, the domain normal-website.com, and the port number 80.

The following image shows how the same-origin policy will be applied if content at the above URL tries to access other origins:

same-origin policy

Hence two URLs are considered to be of same origin if they have same value of these three factors:

SchemePort numberDomain

This means if the origins of two resources match, JavaScript code on one resource can access and manipulate the other resource. However, if the origins differ, the SOP restricts access.

Consider this scenario:

Imagine you’re browsing the internet. You visit your favorite online shopping website, example.com. To log in, you enter your credentials, and the website sets a session cookie on your computer. This cookie contains information about your login session, such as your user ID and authentication token.

Now, let’s say you visit a malicious website, malicious.com. If the malicious website can trick you into clicking on a link or loading content from example.com, it can send an HTTP request to example.com.

Without SOP:

If the SOP didn’t exist, the browser would include the example.com session cookie in its request. When example.com receives the request, it would recognize the cookie and process it as if it came from your browser directly. This could allow the malicious website to:

Access your account: The malicious website could use the session cookie to log in to your account on example.com without your knowledge.Steal sensitive information: The malicious website could access your personal information, order history, or payment details.Perform unauthorized actions: The malicious website could place orders, change your password, or perform other actions on your behalf.

With SOP:

However, due to the SOP, the browser would consider this request of different origin and hence would not include the example.com session cookie in its request. This is because the request is coming from a different origin (malicious.com). The browser will prevent the cookie from being sent, protecting your account from unauthorized access.

The SOP controls what JavaScript code is allowed to do when it tries to interact with content loaded from a different origin (e.g., a different domain, port, or protocol).

Although SOP restricts JavaScript from directly interacting with cross-origin content, loading some types of external resources (e.g., images, videos, or scripts) from another origin is allowed. However, reading the contents of those resources is blocked.

This means that although the content like video or an image will be loaded cross-domain and displayed but the JS code running on that page will not be able to directly interact with the embedded content eg- modifying the data or interacting with the metadata etc.

Therefore SOP allows embedding of images via the <img> tag, media via the <video> tag and JavaScript includes with the <script> tag but does not let the java script code to directly interact with the embedded data. So this means that JS will not be able to read the pixel data of the embedded image, it will not be able to access the metadata of the embedded video etc.

There are some exceptions to Same Origin Policy:

Some objects are writable but not readable cross-domain, such as the location object or the location.href property from iframes or new windows.Some objects are readable but not writable cross-domain, such as the length property of the window object (which stores the number of frames being used on the page) and the closed property.

Further due to legacy requirements, the same-origin policy is more relaxed when dealing with cookies, so they are often accessible from all subdomains of a site even though each subdomain is technically a different origin. To mitigate the risk we can use the HttpOnly flag.

The HttpOnly flag is a setting that can be applied to cookies to restrict access to them. When a cookie is marked with this flag:

It can only be sent with HTTP requests (like those made when navigating to a new page or making API calls).

It cannot be accessed or modified by JavaScript running in the browser.

Risk without HttpOnly:

If cookies are accessible via JavaScript, malicious scripts (like those injected through cross-site scripting, or XSS) can steal cookies, including sensitive ones like session tokens.

Example of an attack:

A website sets a cookie to manage the login session.An attacker injects a malicious script into the webpage that reads document.cookie.The attacker sends the session cookie to their server, gaining access to the account.

Benefit of HttpOnly:

Marking a cookie as HttpOnly ensures that:

1. Even if an attacker successfully injects a script, it cannot read the cookie using document.cookie.

2. The cookie is only sent in HTTP headers during legitimate requests, reducing the risk of theft.

Limited interaction due to SOP:

By default, subdomains are treated as separate origins. For example:marketing.example.com and example.com have different origins due to their subdomain differences.

This means they cannot directly interact with each other under SOP.

Relaxing SOP using document.domain:

If we have control over both the domains (e.g., marketing.example.com and example.com), we can use the document.domain property of the document object in java script to make them appear as if they have the same origin. Both domains need to set document.domain = "example.com"; in their JavaScript code.

This makes their origin common, effectively bypassing the SOP restriction. Now, these domains can freely share content, cookies, and other resources as though they are part of the same origin.

In the past it was possible to set document.domain to a TLD such as com, which allowed access between any domains on the same TLD, but now modern browsers prevent this.

What is FQDN (Fully Qualified Domain Name)

It is complete address of the domain on the internet and specifies exact location of a resource in the hierarchy of the Domain Name System (DNS).

Structure of an FQDN:

An FQDN consists of several parts:

Subdomain (optional):This is a specific section of a website. For example, marketing or blog in marketing.example.com.

2. Domain name:

The main identifier, such as example in example.com.

3. Top-Level Domain (TLD):

The suffix, such as .com, .org, or .net.

4. Root domain (hidden):

Represented as a dot (.) at the end of an FQDN, signifying the topmost level in DNS (e.g., example.com.).

Example of FQDN:

For the domain marketing.example.com:

Subdomain: marketingDomain: exampleTLD: comFQDN: marketing.example.com. (though the trailing . is often implied and hidden in browsers).

Note that SOP can only be relaxed if the string in “document.domain” property of the document object in java script is a part of FQDN (fully qualified domain name) of both the origins. Here in this case “example.com” is part of both the FQDNs.