Understanding Same-Origin Policy and CORS: Fundamentals, Request Types, and Security Considerations

Preface

In a recent interview for a ByteDance position, the author encountered a high‑frequency front‑end interview question about POST requests, which touches many concepts. The following sections provide a detailed explanation.

Same-Origin Policy

Browsers allow many resources (JavaScript, images, audio, video, etc.) to be loaded from different origins, but unrestricted access leads to security risks such as XSS, SQL injection, OS command injection, HTTP header injection, CSRF, and others. To protect user data, browsers enforce the Same‑Origin Policy.

What Is the Same-Origin Policy?

The Same‑Origin Policy restricts how a document or script loaded from one origin can interact with resources from another origin. Two URLs are considered same‑origin when their protocol, host, and port are identical.

Protocol: Defines how data is exchanged (e.g., HTTP, HTTPS).

Host: The computer or device connected to a network that provides resources.

Port: The endpoint for process‑to‑process communication.

Example comparison with the URL http://test.home.com:8080/dir/page.html :

URL

Result

Reason

http://test.home.com:8080/dir/page.html

Same Origin

Only the path differs

http://test.home.com:8080/dir/inner/another.html

Same Origin

Only the path differs

https://test.home.com:8080/secure.html

Different Origin

Different protocol (HTTP vs HTTPS)

http://test.home.com:8081/dir/etc.html

Different Origin

Different port

http://online.home.com:8080/dir/other.html

Different Origin

Different host

The Same‑Origin Policy manifests in three areas: DOM access, web data access, and network communication.

DOM Access Restriction: Scripts cannot read or manipulate the DOM of a page from a different origin.

Web Data Restriction: XMLHttpRequest and Fetch can only target resources that share the same origin, preventing CSRF attacks.

Network Communication Restriction: Browsers block cross‑origin network responses unless explicitly allowed.

CORS (Cross‑Origin Resource Sharing)

CORS is a mechanism that allows controlled cross‑origin requests. Browsers may block the response of a cross‑origin request even if the request itself succeeds; this is where CORS headers come into play.

The browser isolates different origins in separate processes. If a cross‑origin response contains sensitive data, the rendering process may be prevented from accessing it (CORB – Cross‑Origin Read Blocking).

CORB is a security mechanism that prevents malicious scripts from reading cross‑origin responses before they reach the rendering process.

CORS works by having the server include specific HTTP headers that indicate which origins are allowed. For non‑simple requests, the browser first sends a preflight OPTIONS request.

Simple Requests

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

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 ReadableStream objects are used.

No custom request headers are present.

No event listeners are attached to XMLHttpRequestUpload .

Preflight Requests

For non‑simple requests, the browser sends a preflight OPTIONS request to determine whether the actual request is safe. The preflight includes two special headers:

Access-Control-Request-Method : the HTTP method that will be used (e.g., POST).

Access-Control-Request-Headers : a comma‑separated list of additional headers the actual request will send (e.g., content-type,x-secsdk-csrf-token ).

If the server approves, it responds with headers such as Access-Control-Allow-Origin , Access-Control-Allow-Methods , Access-Control-Allow-Headers , and optionally Access-Control-Max-Age (caching duration for the preflight result).

Credentials and Wildcards

When a request includes credentials (cookies, HTTP authentication), the server must not use a wildcard ( * ) for Access-Control-Allow-Origin ; it must echo back the specific origin (e.g., https://example.com ). Similarly, Access-Control-Allow-Headers and Access-Control-Allow-Methods should list explicit values rather than * to avoid security risks.

Complete Request Flow Diagram

The following diagram (image) illustrates the full CORS request lifecycle, from the initial simple or preflight request to the final response handling.

Summary

A preflight request is an automatic OPTIONS request sent by the browser during a CORS exchange. Its purpose is to let the server decide whether to permit the actual cross‑origin request, thereby protecting user data and privacy.

Cross‑origin requests are blocked by default because of the Same‑Origin Policy. When a page needs to access a different origin, the browser first checks the server’s CORS headers; if they allow the origin, method, and headers, the browser proceeds with the actual request.

Using preflight requests and properly configured CORS headers effectively mitigates the security risks associated with cross‑origin resource sharing.