Information Security 11 min read

Understanding Same-Origin Policy and CORS in Web Development

This article explains the fundamentals of the Same‑Origin Policy, its security implications, and how Cross‑Origin Resource Sharing (CORS) works—including simple requests, preflight requests, and handling credentials—to help developers safely perform cross‑domain HTTP operations in browsers.

Architect
Architect
Architect
Understanding Same-Origin Policy and CORS in Web Development

The Same‑Origin Policy is a core security mechanism that restricts how a document or script loaded from one origin can interact with resources from another origin, preventing attacks such as XSS, SQL injection, OS command injection, HTTP header injection, and CSRF.

Two URLs are considered same‑origin when their protocol, host, and port are identical. The policy limits DOM access, web data loading (e.g., XMLHttpRequest or Fetch), and network communication across origins.

Simple Request

A simple request does not trigger a CORS preflight. It must use only GET, HEAD, or POST methods, limited standard headers (Accept, Accept‑Language, Content‑Language, Last‑Event‑ID, Content‑Type with specific MIME types), no custom headers, no ReadableStream, and no XMLHttpRequestUpload event listeners.

Preflight Request

For non‑simple requests, the browser sends an OPTIONS preflight request to determine if the server permits the actual request. The preflight includes Access-Control-Request-Method and Access-Control-Request-Headers headers, and the server responds with corresponding Access-Control-Allow-* headers.

Access-Control-Allow-Origin specifies allowed origins (cannot be "*" when credentials are included).

Access-Control-Allow-Methods lists permitted HTTP methods.

Access-Control-Allow-Headers lists allowed custom headers.

Access-Control-Max-Age defines how long the preflight result can be cached.

After a successful preflight, the actual request proceeds with an Origin header, and the server must include Access-Control-Allow-Origin in its response.

Credentials and Wildcards

When a request includes credentials (e.g., cookies), the server must not use a wildcard "*" for Access-Control-Allow-Origin ; it must echo the requesting origin. Likewise, Access-Control-Allow-Headers and Access-Control-Allow-Methods should list explicit values rather than "*" to avoid security risks.

In summary, the preflight mechanism and CORS headers enable controlled cross‑origin communication while protecting user data and preventing malicious exploitation.

httpCORSCross-OriginbrowserWeb Securitysame-origin
Architect
Written by

Architect

Professional architect sharing high‑quality architecture insights. Topics include high‑availability, high‑performance, high‑stability architectures, big data, machine learning, Java, system and distributed architecture, AI, and practical large‑scale architecture case studies. Open to ideas‑driven architects who enjoy sharing and learning.

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.