CORS and How It Works Behind the Scenes

Cross-Origin Resource Sharing (CORS) is a security feature implemented by web browsers to control and restrict web page scripts from making requests to a different domain than the one that served the web page. It is designed to prevent cross-site request forgery (CSRF) and other security vulnerabilities. CORS works by adding additional HTTP headers to the response from the server to inform the browser whether it’s allowed to make requests to the server from a different origin (domain).

Here’s how CORS works behind the scenes:

1. Origin Determination:
When a web page makes a request to a different domain, the browser checks the origin of the request. An origin is composed of three parts: the protocol (http or https), the domain (e.g., example.com), and the port (if not the default for the protocol). For example, the origin of “https://example.com:8080" is “https://example.com."

2. Same-Origin Policy:
By default, web browsers enforce the Same-Origin Policy, which restricts web pages from making requests to domains other than the one that served the web page. This policy prevents malicious scripts from accessing data from other domains.

3. CORS Request:
When a web page attempts to make a cross-origin request (e.g., an XMLHttpRequest or Fetch API call), the browser automatically includes an “Origin” header in the HTTP request. This header specifies the origin of the requesting page.

4. Server-Side Handling:
The server receiving the request checks the “Origin” header to determine whether it should allow the request from this origin. If the server allows the request, it includes the appropriate CORS response headers in its HTTP response. The key response headers for CORS are:

— `Access-Control-Allow-Origin`: This header specifies which origin(s) are allowed to access the server’s resources. It can be a specific origin or a wildcard (“*”) to allow any origin.

— `Access-Control-Allow-Methods`: This header lists the HTTP methods (e.g., GET, POST, PUT) that are allowed for cross-origin requests.

— `Access-Control-Allow-Headers`: This header specifies which headers can be included in the actual request.

— `Access-Control-Allow-Credentials`: This header indicates whether the browser should include credentials (e.g., cookies or HTTP authentication) in the request.

— `Access-Control-Expose-Headers`: This header lists the headers that can be exposed to the requesting client.

5. Browser Handling:
The browser checks the CORS headers in the response to determine whether the request is allowed. If the server’s CORS headers permit the request, the browser allows the response to be delivered to the web page. If the server’s CORS headers do not allow the request, the browser blocks the response, and the web page’s JavaScript won’t be able to access the data.

6. Preflight Requests (Optional):
For more complex requests, the browser may send a preflight request using the HTTP OPTIONS method to check if the server allows the actual request. This preflight request includes the “Origin” header and other CORS-related headers, allowing the server to validate the request before the actual request is sent.

Preflight requests are typically used in the following scenarios:

1. Request Methods Other than Simple Methods: When the web page is making a cross-origin request using HTTP methods other than simple methods (e.g., GET, POST, or HEAD), a preflight request is sent. Simple methods do not trigger preflight requests.
2. Custom Headers: If the request includes custom headers that are not considered simple headers, a preflight request is sent. Simple headers include common headers like “Accept,” “Accept-Language,” or “Content-Type” with values such as “application/x-www-form-urlencoded,” “multipart/form-data,” or “text/plain.”
3. Credentials: When the request includes credentials (e.g., cookies or HTTP authentication), a preflight request is typically sent to confirm that the server allows cross-origin requests with credentials.
4. Non-standard Content Types: If the request has a Content-Type other than those commonly used for simple requests, a preflight request may be sent.

The purpose of the preflight request is to ask the server for permission to make the actual request by checking the server’s CORS-related headers, including Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Headers. If the server responds with the appropriate CORS headers allowing the preflight request, the browser will proceed to make the actual request. If the server does not allow the preflight request, the actual request will not be sent, and the web page's JavaScript will not receive a response.

In many cases, simple cross-origin requests can proceed without the need for a preflight request, which helps reduce unnecessary overhead and latency in client-server communication. The decision to send a preflight request is based on the request characteristics and the server’s CORS configuration.

CORS provides a mechanism for servers to define which origins are permitted to access their resources and helps prevent unauthorized cross-origin requests, enhancing web security. It allows web applications to interact with APIs and resources hosted on different domains while maintaining security and privacy.

Resources:

In Plain English

Thank you for being a part of our community! Before you go:

• Be sure to clap and follow the writer! 👏
• You can find even more content at PlainEnglish.io 🚀
• Sign up for our free weekly newsletter. 🗞️
• Follow us: Twitter(X), LinkedIn, YouTube, Discord.
• Check out our other platforms: Stackademic, CoFeed, Venture.