Understanding Same-Origin Policy and CORS: Core Concepts, Simple Requests, and Preflight Mechanics

In modern browsers, the same‑origin policy restricts how a document or script from one origin can interact with resources from another origin, preventing security issues such as XSS, CSRF, SQL injection, and other attacks.

An origin is defined by the combination of protocol, host, and port. For example, the URL http://test.home.com:8080/dir/page.html is considered same‑origin with http://test.home.com:8080/dir/inner/another.html , but differs from https://test.home.com:8080/secure.html (different protocol), http://test.home.com:8081/dir/etc.html (different port), or http://online.home.com:8080/dir/other.html (different host).

The same‑origin policy manifests in three main areas:

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

Web data restriction: XMLHttpRequest or Fetch API calls are limited to the same origin unless the server explicitly permits cross‑origin access via CORS.

Network communication restriction: Browsers block responses from cross‑origin requests unless allowed by CORS headers.

CORS (Cross‑Origin Resource Sharing) is a mechanism that allows a server to specify which origins may access its resources. When a request is not a simple request, the browser first sends a preflight OPTIONS request containing headers such as Access-Control-Request-Method and Access-Control-Request-Headers . The server responds with Access-Control-Allow-Origin , Access-Control-Allow-Methods , and other headers to indicate permission.

A simple request does not trigger a preflight and must meet the following conditions:

HTTP method is GET, HEAD, or POST.

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

No use of ReadableStream objects.

No custom request headers.

No event listeners on XMLHttpRequestUpload .

For preflight requests , the browser sends an OPTIONS request with the special headers mentioned above. If the server approves, subsequent actual requests include an Origin header and the server’s response includes Access-Control-Allow-Origin .

When credentials (e.g., cookies) are included, the server must not use a wildcard ( * ) for Access-Control-Allow-Origin ; it must echo the requesting origin (e.g., https://example.com ) to allow the request to succeed.

The article also provides a complete request flow diagram (image) illustrating the interaction between the browser, preflight request, and actual request.

In summary, preflight requests are an automatic OPTIONS request issued by browsers during CORS to ensure that cross‑origin requests are safe, allowing servers to decide whether to permit the actual request based on the provided headers.