The Same-Origin Policy

Browser security architecture relies fundamentally on the concept of an origin. An origin is strictly defined by the triplet consisting of the protocol, the hostname, and the port number. Two resources are considered same-origin only if all three components match exactly.

Developers can inspect the current origin via window.origin or location.origin.

// Example origins
const originA = "https://client.example.com";
const originB = "https://api.example.com";
// These are different origins due to hostname mismatch

const originC = "http://site.com/page";
const originD = "http://site.com/script.js";
// These are same-origin; path does not affect origin definition

const localA = "http://localhost:3000";
const localB = "http://127.0.0.1:3000";
// These are different origins; localhost and 127.0.0.1 are distinct hostnames

Policy Definition

The Same-Origin Policy (SOP) restricts how a document or script loaded from one origin can interact with a resource from another origin. Specifically, JavaScript executing within Origin A is prohibited from reading data belonging to Origin B.

Consider a scenario where client.example.com includes a script hosted at api.example.com. Once loaded, that script executes within the security context of client.example.com. It cannot access data from api.example.com unless explicitly permitted, regardless of where the script file was physically downloaded from.

Security Rationale

The primary purpose of SOP is privacy and data protection. Without this isolation, malicious actors could easily exfiltrate sensitive information.

Imagine a user is logged into a banking portal at secure.bank.com. If a malicious site fake-bank.com could make arbitrary requests to secure.bank.com on behalf of the user, it could retrieve account balances or transaction history. The browser prevents this by ensuring that scripts from fake-bank.com cannot read responses from secure.bank.com.

Root Cause

The vulnerability exists because HTTP requests initiated by different sites look nearly identical to the server. While the Referer header might indicate the source, relying on it is insufficeint because:

1. Headers can be spoofed or stripped by proxies.
2. Backend developers might fail to validate them.

Security chains are only as strong as their weakest link. Therefore, the browser enforces isolation at the client level to protect user data regardless of server-side configuration.

Understanding Cross-Origin Restrictions

Cross-origin issues arise when a web application attempts to request resources from a domain different from its own. Several specific scenarios often cause confusion:

• Subdomains: app.example.com accessing example.com is cross-origin. Historically, different entities may host services on different subdomains.
• Ports: example.com:80 and example.com:8080 are distinct origins. Different services often run on different ports.
• IP Addresses: Accessing via IP address versus domain name is treated as cross-origin, even if they resolve to the same server.

Static Resources Exception

The SOP restricts data access (like AJAX responses), not resource loading. Tags such as <img>, <script>, and <link> can load cross-origin resources because the browser does not expose the content of these resources to JavaScript directly; it merely renders or executes them.

Cross-Origin Resource Sharing (CORS)

CORS is a mechanism that allows restricted resources on a web page to be requested from another domain outside the domain from which the first resource was served. It relaxes the SOP in a controlled manner.

Mechanism

CORS relies on additional HTTP headers exchanged between the browser and the server. The server indicates which origins are permitted to access its resources. If client.example.com needs data from api.service.io, the server at api.service.io must include specific headers in its response.

Request Classifications

CORS requests are categorized into simple requests and preflighted (complex) requests.

Simple Requests

A request is considered simple if it meets specific criteria:

• Method is GET, HEAD, or POST.
• Headers are limited to safe lists (e.g., Accept, Content-Language).
• Content-Type is one of: application/x-www-form-urlencoded, multipart/form-data, or text/plain.

The browser automatically adds an Origin header to simple requests.

GET /data HTTP/1.1
Origin: https://client.example.com
Host: api.service.io
...

If the server accepts the origin, it responds with:

Access-Control-Allow-Origin: https://client.example.com
Access-Control-Allow-Credentials: true
Content-Type: application/json

• Access-Control-Allow-Origin: Mandatory. Specifies the allowed origin or * for public access.
• Access-Control-Allow-Credentials: Optional. Indicates if cookies can be included. If true, the client must also set withCredentials.
• Access-Control-Expose-Headers: Optional. Allows the browser to expose specific response headers to JavaScript.

If the header is missing or the origin mismatches, the browser blocks the response and throws a network error in the console.

Complex Requests

Requests that do not meet the simple criteria (e.g., using PUT, DELETE, or application/json) trigger a preflight request. The browser sends an OPTIONS request first to verify safety.

const serviceUrl = "https://api.service.io/update";
const request = new XMLHttpRequest();

request.open("DELETE", serviceUrl, true);
request.setRequestHeader("X-Auth-Token", "secure_token_value");
request.send();

Before sending the DELETE request, the browser sends:

OPTIONS /update HTTP/1.1
Origin: https://client.example.com
Access-Control-Request-Method: DELETE
Access-Control-Request-Headers: X-Auth-Token

The server must respond affirmatively to the OPTIONS request before the actual request proceeds.

Legacy Support

Older vesrions of Internet Explorer (IE8/9) do not support standard CORS via XMLHttpRequest. They require the proprietary XDomainRequest object.

JSONP Alternative

Before CORS became widely supported, JSON with Padding (JSONP) was the standard workaround for cross-origin data retrieval.

Implementation

JSONP exploits the fact that <script> tags are not subject to SOP. The client defines a callback function, and the server returns JavaScript code that executes this function with the data as an argument.

const callbackIdentifier = "handleData";
const scriptElement = document.createElement("script");
const sourceUrl = `https://legacy.api.io/fetch?uid=456&callback=${callbackIdentifier}`;

scriptElement.src = sourceUrl;
document.body.appendChild(scriptElement);

window.handleData = function(payload) {
    console.log("Received JSONP data:", payload);
    // Cleanup
    document.body.removeChild(scriptElement);
};

Trade-offs

Advantages:

• Compatible with very old browsers.
• No server-side CORS configuration required (if the server supports JSONP).

Disadvantages:

• Security Risk: Executes arbitrary code from the third party, increasing XSS vulnerability.
• Method Limitation: Only supports GET requests.
• Error Handling: Cannot detect HTTP error status codes (e.g., 404, 500) reliably; only script load success/failure is known.