Understanding Same-Origin Policy and CORS: Mechanisms, Preflight Requests, and Security Implications
This article explains the browser's Same‑Origin Policy, its restrictions on DOM, data and network access, and how Cross‑Origin Resource Sharing (CORS) with simple and preflight requests enables controlled cross‑origin communication while mitigating security risks.
The browser allows many resources (JavaScript, images, audio, video, etc.) to be loaded from any site, but unrestricted access creates security problems such as XSS, SQL injection, OS command injection, HTTP header injection, CSRF, and more.
To protect users, browsers enforce the Same‑Origin Policy, which restricts how a document or its scripts can interact with resources from a different origin. Two URLs are considered same‑origin only when their protocol, host, and port all match.
Same‑Origin Policy limits three areas: DOM access (scripts cannot read or manipulate the DOM of a page from another origin), Web data access (XMLHttpRequest or Fetch can only request resources from the same origin), and network communication (cross‑origin network requests are blocked unless explicitly allowed).
Cross‑Origin Resource Sharing (CORS) provides a controlled way to relax these restrictions. The server includes specific HTTP headers (e.g., Access‑Control‑Allow‑Origin) to indicate which origins may access the resource. Browsers first send a preflight OPTIONS request for non‑simple requests to verify the server’s permissions.
A "simple request" does not trigger a preflight and must meet several conditions: only GET, HEAD, or POST methods; only a limited set of safe request headers; no use of ReadableStream objects; no custom headers; and no event listeners on XMLHttpRequestUpload.
For non‑simple requests, the browser sends a preflight request containing headers such as Access‑Control‑Request‑Method, Access‑Control‑Request‑Headers, and expects responses like Access‑Control‑Allow‑Origin, Access‑Control‑Allow‑Methods, Access‑Control‑Allow‑Headers, and Access‑Control‑Max-Age. The server’s response determines whether the actual request proceeds.
When credentials (e.g., cookies) are included, the server must not use a wildcard (*) for Access‑Control‑Allow‑Origin; it must specify the exact origin. Likewise, Access‑Control‑Allow‑Headers and Access‑Control‑Allow‑Methods should list explicit values rather than using * to avoid security risks.
In summary, preflight requests are automatic OPTIONS calls that safeguard cross‑origin interactions, allowing servers to decide which requests are permitted, thereby protecting user data and privacy.
Architecture Digest
Focusing on Java backend development, covering application architecture from top-tier internet companies (high availability, high performance, high stability), big data, machine learning, Java architecture, and other popular fields.
How this landed with the community
Was this worth your time?
0 Comments
Thoughtful readers leave field notes, pushback, and hard-won operational detail here.