Mastering Same-Origin Policy and CORS: A Complete Guide for Secure Web Development

Preface

The author encountered a frequent front‑end interview question about POST requests and uses this article to explain the underlying security concepts.

Same-Origin Policy

The browser restricts how documents and scripts from one origin can interact with resources from another origin to prevent attacks such as XSS, SQL injection, OS command injection, HTTP header injection, and CSRF.

What is Same-Origin Policy

Two URLs are considered same‑origin when they share the same protocol, host, and port.

Protocol : the scheme that defines how data is exchanged (e.g., HTTP, HTTPS).

Host : the networked computer or device providing resources.

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

An example comparison with http://test.home.com:8080/dir/page.html is shown below.

Same‑Origin Policy affects 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 headers are present.

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

CORS

Cross‑Origin Resource Sharing (CORS) lets servers specify which origins may access their resources, overcoming the default Same‑Origin restrictions.

CORB is a security mechanism that prevents malicious scripts from accessing cross‑origin response data before it reaches the rendering process.

Simple Request

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

HTTP method limited to GET, HEAD, or POST.

Allowed headers 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 object used.

No custom request headers.

No event listeners attached to XMLHttpRequestUpload.

Preflight Request

Non‑simple requests cause the browser to send an OPTIONS request (preflight) before the actual request to verify server permission.

The preflight request includes special headers:

Access-Control-Request-Method – the HTTP method to be used (e.g., POST).

Access-Control-Request-Headers – a comma‑separated list of additional headers (e.g., content-type, x-secsdk-csrf-token).

Access-Control-Allow-Origin – specifies allowed origin (e.g., https://xxx.cn or *).

Access-Control-Max-Age – optional cache duration for the preflight response.

When credentials such as cookies are included, the server must not use a wildcard (*) for Access-Control-Allow-Origin; it must echo the requesting origin to allow the request.

Summary

Preflight requests are automatically issued by browsers during CORS to ensure security, allowing servers to decide whether to permit cross‑origin requests. Proper header configuration prevents credential leakage and protects user data and privacy.