CORS Explained: Browser Security for Cross-Origin Resource Sharing

The Same-Origin Policy: A Browser's First Line of Defense

Web browsers employ a fundamental security principle called the Same-Origin Policy (SOP). This policy restricts how a document or script loaded from one origin can interact with resources from another origin. An origin is defined by the combination of three components: the scheme (protocol, like HTTP or HTTPS), the host (domain name, like www.example.com), and the port (e.g., 80 for HTTP, 443 for HTTPS).

If a web page served from https://app.example.com tries to fetch data from https://api.example.com, the browser checks the origin. Since the scheme (https), host (app.example.com vs. api.example.com), and port (implied 443 for both) are not identical, these are considered different origins. This is a cross-origin request.

Without any further mechanisms, the browser would block JavaScript code from reading the response of such a cross-origin request. This prevents malicious websites from stealing sensitive data from other sites you might be logged into. Think of it like a bouncer at a club: the bouncer (the browser) checks IDs (origins) and only lets people (scripts) from the same party (origin) interact freely with each other. Access to other parties requires explicit permission.

Enter CORS: Enabling Controlled Cross-Origin Access

While the SOP is crucial for security, it can hinder legitimate web development. Modern applications often need to fetch data from different domains. For instance, a frontend application hosted on https://frontend.example.com might need to retrieve user data from a backend API hosted on https://api.example.com. This is where Cross-Origin Resource Sharing (CORS) comes into play.

CORS is not a protocol itself, but rather a mechanism that uses additional HTTP headers to tell browsers that a web application, running on one origin, is permitted to access selected resources from a server on a different origin. It’s a way for the server to explicitly grant permission for cross-origin requests, overriding the default SOP restrictions for specific scenarios.

The server hosting the resource sends specific HTTP response headers to the browser. The browser then interprets these headers to decide whether to allow the client-side code to access the requested resource. If the server does not explicitly allow the cross-origin request via these headers, the browser will block the request, and you’ll typically see a CORS error in the developer console.

How CORS Works: The Request and Response Flow

CORS involves communication between the browser, the client-side script, and the server. The process typically follows these steps:

Simple Requests

For certain types of requests, known as simple requests, the browser sends the request directly to the server. A request is considered simple if it meets all the following criteria:

• Uses one of the following HTTP methods: GET, HEAD, or POST.
• Does not use custom HTTP headers, beyond the standard ones like Accept, Accept-Language, Content-Language, Content-Type (with specific allowed values like application/x-www-form-urlencoded, multipart/form-data, or text/plain).

When a simple request is made to a different origin, the browser automatically adds an Origin header to the request. This header indicates the origin of the page making the request (e.g., Origin: https://app.example.com). The server then processes this request and, if it permits cross-origin access, includes specific CORS headers in its response.

Preflighted Requests

For any request that does not meet the criteria for a simple request (e.g., using methods like PUT or DELETE, or including custom headers), the browser first sends a preflight request. This is an OPTIONS HTTP request made to the target URL before the actual request is sent.

The preflight request includes headers that inform the server about the nature of the actual request that the browser intends to make. Key headers in a preflight request include:

• Access-Control-Request-Method: Specifies the HTTP method that the actual request will use (e.g., PUT).
• Access-Control-Request-Headers: Lists the custom headers that the actual request will include (e.g., X-Custom-Header).
• Origin: Indicates the origin of the client making the request.

The server receives the preflight request and checks if it permits requests with the specified method and headers from the given origin. If allowed, the server responds with:

• Access-Control-Allow-Origin: Confirms the allowed origin(s).
• Access-Control-Allow-Methods: Lists the allowed HTTP methods for the resource.
• Access-Control-Allow-Headers: Lists the allowed custom headers.
• Access-Control-Max-Age: Specifies how long the preflight response can be cached by the browser.

If the preflight request is successful and the server's response indicates that the actual request is permitted, the browser then proceeds to send the actual request (e.g., the PUT request). If the preflight request fails or the server’s response does not permit the actual request, the browser blocks the actual request, and a CORS error is logged.