Why Same‑Origin Policy Matters: Mastering CORS and Preflight Requests

Preface

In a recent interview question about POST requests, the author uses this opportunity to explain the underlying concepts that are frequently asked in front‑end interviews.

Same‑Origin Policy

Browsers allow many resources (JS, images, audio, video) to be loaded, but unrestricted access would lead to security issues such as XSS, SQL injection, OS command injection, HTTP header injection, CSRF, etc. The same‑origin policy restricts how a document or its scripts 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 transferred, e.g., HTTP or HTTPS.

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

Port : the communication endpoint between processes.

Example URLs and their same‑origin results:
http://test.home.com:8080/dir/page.html          → Same origin (only path differs)
http://test.home.com:8080/dir/inner/another.html → Same origin (only path differs)
https://test.home.com:8080/secure.html           → Different origin (protocol differs)
http://test.home.com:8081/dir/etc.html           → Different origin (port differs)
http://online.home.com:8080/dir/other.html       → Different origin (host differs)

The same‑origin policy manifests in three areas: DOM access, web data (e.g., XMLHttpRequest/Fetch), and network communication.

DOM access restriction:

Scripts cannot access the DOM of a page from a different origin.

Web data restriction:

XHR/Fetch requests are limited to the same origin, preventing CSRF attacks.

Network communication restriction:

Browsers block cross‑origin responses unless explicitly allowed.

For cross‑origin requests, browsers enforce the policy unless the server provides appropriate CORS headers.

CORS

CORS (Cross‑Origin Resource Sharing) allows controlled cross‑origin requests by having the server include specific HTTP headers. Browsers may block the response even if the request succeeds, a mechanism known as CORB.

CORB prevents malicious code from accessing cross‑origin response data before rendering.

When a page makes a cross‑origin request, the browser first sends a preflight OPTIONS request to determine if the actual request is permitted.

Simple Request

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

HTTP method is GET, HEAD, or POST.

Only allowed request headers are used (e.g., Accept, Accept-Language, Content-Language, Last-Event-ID, and Content-Type limited to 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 registered on XMLHttpRequestUpload.

Preflight Request

For non‑simple requests, the browser sends an OPTIONS request containing special headers such as Access-Control-Request-Method and Access-Control-Request-Headers. The server must respond with appropriate Access-Control-Allow-* headers to grant permission.

Example preflight 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 (cannot be * when credentials are included). Access-Control-Max-Age: how long the preflight result can be cached (e.g., 86400 seconds).

Once the preflight succeeds, subsequent actual requests include an Origin header, and the server must include Access-Control-Allow-Origin in its response.

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 requesting origin. Similarly, Access-Control-Allow-Headers and Access-Control-Allow-Methods should list explicit values rather than * to avoid security risks.

Complete Request Flow Diagram

Conclusion

Preflight requests are automatically issued by browsers as OPTIONS requests to ensure cross‑origin resource sharing is safe. They allow the server to decide whether to permit the actual request, protecting user data and privacy.