Cross-Origin Resource Sharing (CORS) in detail

Cross-Origin Resource Sharing (CORS) is a crucial mechanism in web development that enables secure communication between resources hosted on different domains. By default, web browsers enforce the Same-Origin Policy, restricting a webpage from making requests to a domain other than the one that served the page.

Web browsers use a security feature called Cross-Origin Resource Sharing, or CORS, to prevent websites from requesting resources from a domain other than the one that served the website. It gives servers the ability to control who has access to their resources and what sorts of requests they accept.

What is the Same-Origin Policy (SOP)?

Understanding the Same-Origin Policy is essential before digging into CORS. As a security precaution, browsers enforce the Same-Origin Policy (SOP), which prevents scripts on a web page from requesting data to a domain, protocol, or port other than the one that served the page.

Origin comprises of:

• Protocol (HTTP/HTTPS)
• Domain (example.com)
• Port (default 80 for HTTP and 443 for HTTPS, but can vary)

For example: –

• Page A is served from https://example.com
• Page B is served from https://otherdomain.com

JavaScript running on page A cannot send an HTTP request to page B due to the same-origin policy unless the server at otherdomain.com specifically permits it using CORS.

Why CORS is Needed

Many web applications require interaction with resources (APIs, CDNs, or third-party services) hosted on various origins, which calls for CORS. The same-origin policy would prevent such interactions in the absence of CORS, restricting the functionality of modern web apps.

CORS (Cross-Origin Resource Sharing) serves as an extension of the Same-Origin Policy. While cross-origin queries are blocked by the SOP, CORS permits certain cross-origin requests to be made, but only if the server provides permission. To enable cross-origin resource sharing, the browser must receive particular CORS headers from the server.

How CORS Works

The way CORS operates is by utilizing HTTP headers to regulate how the requests from one origin (http://example.com) can access resources on another origin (http://api.example.com).

CORS Request Flow

A browser automatically includes an Origin header, which identifies the domain from which the request is coming, in any cross-origin HTTP request. After that, the server on the target origin returns specific HTTP headers indicating whether or not to authorize the request.

• Request: The Origin header, which includes the requesting site’s domain, is sent with the request by the browser.

• Response: After verifying that the Origin is authorized to access the resource, the server replies with an Access-Control-Allow-Origin header.

Important CORS Headers

1. Request Headers (by the browser)
2. Response Headers (by the server)

• Access-Control-Allow-Origin: Indicates which sources are permitted to use the resource. It can use `*` to accept all sources or specify a specific domain (http://example.com). Access-Control-Allow-Origin: http://mywebsite.com
• Access-Control-Allow-Methods: Describes the HTTP methods that are acceptable for cross-origin requests, such as GET, POST, PUT, and DELETE. Access-Control-Allow-Methods: GET, POST
• Access-Control-Allow-Headers: Indicates which headers (such as Authorization and Content-Type) may be used in the HTTP request. Access-Control-Allow-Headers: Content-Type, Authorization
• Access-Control-Allow-Credentials: Indicates whether credentials (such as cookies or HTTP authentication) can be included in the request. Cross-origin requests can include credentials like cookies if this header is set to true. Access-Control-Allow-Credentials: true
• Access-Control-Max-Age: Determines how long the results of a preflight request can be cached (in seconds). Access-Control-Max-Age: 86400 (24 hours)

Simple Requests v/s Preflight Requests

Simple requests and preflight requests are the two categories of cross-origin requests in CORS.

A simple request is one for which a preflight check by the browser is not required. The request must meet specific criteria to be considered a simple request:

• HTTP methods must be one of GET, POST, or HEAD.
• Headers: Only a few specific headers like Accept, Content-Type with specific MIME types, Origin are allowed in the request.

The browser automatically sends preflight requests, before the real request to see if the server will accept it. This happens for:

• Non-simple methods like PUT, DELETE, or PATCH.
• Requests that contain custom headers like Authorization or custom Content-Type.

The browser sends an OPTIONS request (the preflight request) to the server, requesting permission to make the actual request. When the browser receives a response from the server indicating that the request is allowed, it makes the actual request.

In case, you want to learn more about “CORS” and gain in-depth knowledge on full-stack development, consider enrolling for GUVI’s certified Full-stack Development Course that teaches you everything from scratch and make sure you master it!

Conclusion

Cross-Origin Resource Sharing (CORS) is a crucial mechanism in web development that enables secure communication between resources hosted on different domains. By default, web browsers enforce the Same-Origin Policy, restricting a webpage from making requests to a domain other than the one that served the page.