Why Does Your Browser Block Cross‑Origin Requests? Understanding Same‑Origin Policy & CORS

Introduction

During a recent interview at ByteDance, the candidate was asked a high‑frequency front‑end question about POST requests, which actually touches many underlying concepts. This article walks through those concepts step by step.

Same‑Origin Policy

The Same‑Origin Policy is a fundamental security mechanism that restricts how a document or its scripts can interact with resources from another origin. An origin is defined by the combination of protocol, host, and port. If any of these differ, the resources are considered cross‑origin.

Without such restrictions, browsers would be vulnerable to attacks such as XSS, SQL injection, OS command injection, HTTP header injection, CSRF, and others.

The policy manifests in three areas:

DOM access restriction: scripts cannot read or manipulate the DOM of a page from a different origin.

Web data restriction: XMLHttpRequest or Fetch can only request resources from the same origin unless CORS is used.

Network communication restriction: browsers block cross‑origin network responses unless explicitly allowed.

Because of these limits, browsers only allow cross‑origin HTTP requests when the server provides appropriate CORS headers.

CORS

CORS (Cross‑Origin Resource Sharing) is a mechanism that lets a server specify which origins may access its resources. The browser first sends a preflight OPTIONS request to discover the server’s policy, then proceeds with the actual request if allowed.

CORB (Cross‑Origin Read Blocking) further protects users by preventing the rendering process from accessing potentially malicious cross‑origin data.

Simple Request

A request is considered simple and does not trigger a preflight if it meets all of the following conditions:

Uses only GET, HEAD, or POST methods.

Contains only safe headers such as Accept, Accept‑Language, Content‑Language, Last‑Event‑ID, and Content‑Type (limited to application/x-www-form-urlencoded, multipart/form-data, or text/plain).

Does not use a ReadableStream object.

Does not include custom request headers.

No event listeners are attached to the XMLHttpRequestUpload object.

Preflight Request

For non‑simple requests, the browser automatically sends a preflight OPTIONS request to the server. This request includes special headers: Access-Control-Request-Method: the HTTP method that will be used in the actual request. Access-Control-Request-Headers: a comma‑separated list of custom headers the actual request will send.

The server responds with headers such as Access-Control-Allow-Origin, Access-Control-Allow-Methods, Access-Control-Allow-Headers, and optionally Access-Control-Max-Age to indicate how long the preflight result can be cached.

Requests with Credentials and Wildcards

When a request includes credentials (e.g., cookies), the server must not use the wildcard * for Access-Control-Allow-Origin. Instead, it must echo back the specific origin (e.g., https://example.com) to allow the request.

Similarly, the server should avoid wildcard values for Access-Control-Allow-Headers and Access-Control-Allow-Methods. Explicitly listing allowed headers and methods reduces the risk of abuse.

Full Request Flow Diagram

Conclusion

The preflight request is an automatic OPTIONS request sent by browsers during CORS exchanges to ensure security. It allows the server to decide whether to permit the actual cross‑origin request based on the supplied headers.

By using CORS correctly—specifying exact origins, allowed methods, and headers—developers can safely enable cross‑origin communication while protecting user data and privacy.