Understanding Same-Origin Policy and CORS: A Comprehensive Guide

Same‑origin policy is a fundamental security mechanism that restricts how a document or script loaded from one origin can interact with resources from another origin. An origin is defined by the protocol, host, and port of a URL.

If these three components differ, the browser treats the request as cross‑origin, which can lead to security risks such as XSS, CSRF, SQL injection, and others. Therefore, browsers enforce same‑origin policy to protect user data.

The policy affects three main areas: DOM access, web data (e.g., XMLHttpRequest or Fetch API), and network communication. Scripts cannot directly access the DOM of a page from a different origin, and cross‑origin network requests are blocked unless the server explicitly allows them.

Cross‑Origin Resource Sharing (CORS) provides a controlled way to relax the same‑origin restrictions. When a browser makes a cross‑origin request, it first sends a preflight OPTIONS request to the server. The server responds with CORS headers such as Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Headers to indicate which origins, methods, and headers are permitted.

A request is considered a simple request if it meets all of the following conditions:

Uses only the GET, HEAD, or POST method.

Contains only safe request headers (e.g., Accept, Accept-Language, Content-Type with values 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 XMLHttpRequestUpload.

Non‑simple requests trigger a preflight request. The preflight 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 the actual request will send.

Servers must respond to the preflight with appropriate CORS headers. For requests that include credentials (cookies, HTTP authentication), the Access-Control-Allow-Origin header cannot be a wildcard ( *); it must specify the exact origin (e.g., https://example.com).

Similarly, Access-Control-Allow-Headers and Access-Control-Allow-Methods should list explicit values rather than using a wildcard to avoid security risks.

Below is an example table comparing URLs and their same‑origin status:

URL

Result

Reason 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

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

In summary, preflight requests are automatically issued by browsers during CORS exchanges to ensure that cross‑origin requests are safe. Proper configuration of CORS headers—avoiding wildcards for origins, methods, and headers—helps protect user data and maintain secure web interactions.