Understanding Same‑Origin Policy and CORS: Security Strategies for Web Applications

In modern browsers, any resource such as JavaScript files, images, audio, or video can be loaded from external sites, but unrestricted access creates security risks like XSS, SQL injection, OS command injection, HTTP header injection, and CSRF.

What Is the Same‑Origin Policy

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

Example comparison (URL http://test.home.com:8080/dir/page.html ):

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

The policy manifests in three main areas:

DOM access restriction : Scripts cannot read or manipulate the DOM of a page from another origin.

Web data restriction : XMLHttpRequest or 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 provides a controlled way for browsers to request resources from a different origin. The server includes specific HTTP headers to indicate which origins are permitted.

Simple Requests

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

Uses only GET, HEAD, or POST methods.

Contains only standard headers such as Accept , Accept-Language , Content-Language , Last-Event-ID , and Content-Type (limited to application/x-www-form-urlencoded , multipart/form-data , or text/plain ).

Does not use a ReadableStream object.

Does not include any custom request headers.

No event listeners are registered on the XMLHttpRequestUpload object.

Preflight (OPTIONS) Requests

For non‑simple requests, the browser first sends an OPTIONS request (preflight) to the server to determine whether the actual request is safe to send.

The preflight request includes two special headers:

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

Access-Control-Request-Headers : a comma‑separated list of custom headers the actual request intends to send.

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 to cache the permission.

CORB (Cross‑Origin Read Blocking) is a security mechanism that blocks malicious scripts from accessing cross‑origin responses before they reach the rendering process.

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

Summary

Preflight requests are automatically issued by browsers during CORS interactions to ensure that cross‑origin requests are explicitly authorized by the server, thereby protecting user data and privacy.

By enforcing the Same‑Origin Policy and using CORS with proper header configuration, web applications can safely perform cross‑domain communication while mitigating common security threats.