CORS Explained: Why Browsers Block Cross-Origin API Requests

The modern web relies heavily on APIs, often requiring communication between different domains. However, browsers implement a security measure called the same-origin policy to prevent scripts from accessing resources hosted on a different domain. This policy is in place to protect users from various security threats, such as cross-site scripting and session hijacking.

When a web page makes a request to an API hosted on a different origin (domain, protocol, or port), the browser blocks the response unless the server explicitly allows it through Cross-Origin Resource Sharing (CORS). CORS is a mechanism that allows servers to declare which origins are trusted to access their resources. This is done by including specific headers in the API response, such as Access-Control-Allow-Origin.

The origin of a URL is determined by the combination of its scheme (http or https), hostname (the domain name), and port number. For example, https://wpmm.jp and https://en.wpmm.jp are considered different origins because they have different hostnames, even though they share the same scheme and port. Similarly, https://wpmm.jp and http://wpmm.jp are different origins due to the difference in schemes.

When a browser encounters a request to a different origin, it first checks if the server has sent a CORS-compatible response. If the server includes an Access-Control-Allow-Origin header with the value set to the requesting origin or a wildcard (*), the browser permits the response to be read by the JavaScript running in the browser.

However, if the server includes an Access-Control-Allow-Credentials header set to true alongside the wildcard origin, the browser will only allow the response to be read if the request included credentials like cookies or an Authorization header.

There are two main types of CORS requests: simple and non-simple. Simple requests include GET, HEAD, and POST requests with certain content types (application/x-www-form-urlencoded, multipart/form-data, or text/plain). For these types of requests, the browser sends the request directly and then decides whether to expose the response based on the headers it receives.

Non-simple requests, such as POST requests with different content types (like application/json or multipart/form-data), trigger a preflight request. The browser sends an OPTIONS request first to check if the server allows the actual request. The server responds with headers like Access-Control-Allow-Methods and Access-Control-Allow-Headers, indicating which HTTP methods and headers are allowed.

Only after the server responds to the preflight request with the appropriate headers will the browser send the actual request.

In summary, CORS is a crucial security feature that allows servers to control which origins can access their resources. By explicitly declaring trusted origins through headers in the API response, servers can safely relax the browser's same-origin policy and enable cross-origin API calls while preventing unauthorized access to sensitive data.