What Is an Origin?
In web security, an origin is defined by the combination of:
- Protocol (http or https)
- Domain (example.com)
- Port (80, 443, 3000)
Two URLs are considered the same origin only if all three components match exactly. Any difference makes them cross-origin.
What Is the Same-Origin Policy (SOP)?
The Same-Origin Policy is a browser-enforced security rule that prevents one origin from accessing sensitive data from another origin.
Its primary purpose is to protect users from malicious websites that could otherwise read private data from trusted sites.
What SOP Restricts
- Reading responses from another origin
- Accessing cookies and local storage of another site
- Reading DOM content of another site
What SOP Allows
- Sending requests to other origins
- Embedding resources (images, scripts, videos)
- Submitting cross-origin forms
The key idea: sending is allowed, reading is restricted.
Why the Same-Origin Policy Is Necessary
Without SOP, a malicious website could:
- Read emails from a logged-in email service
- Steal banking data from open sessions
- Access private APIs using stored cookies
SOP acts as the browser’s first line of defense.
The Problem SOP Creates for Modern Web Apps
Modern architectures often separate frontend and backend systems.
- Frontend hosted on one domain
- Backend API hosted on another domain
Under strict SOP rules, browsers would block frontend apps from reading API responses. This is where CORS becomes necessary.
What Is CORS (Cross-Origin Resource Sharing)?
CORS is a security mechanism that allows servers to explicitly tell browsers which cross-origin requests are permitted.
CORS does not disable the same-origin policy. Instead, it adds controlled exceptions to it.
How CORS Works Conceptually
CORS shifts the decision from the browser alone to a collaboration between browser and server.
- Browser enforces SOP by default
- Server responds with CORS headers
- Browser decides whether to allow access
Simple CORS Request Flow
- Browser sends a request to another origin
- Server responds with Access-Control-Allow-Origin
- Browser checks if the origin is allowed
- If allowed, response is accessible to JavaScript
CORS Headers Explained
Access-Control-Allow-Origin
Specifies which origins are allowed to access the resource.
- * (allows all origins – limited use)
- https://example.com (specific origin)
Access-Control-Allow-Methods
Defines which HTTP methods are allowed.
Access-Control-Allow-Headers
Specifies which custom headers can be sent.
Access-Control-Allow-Credentials
Allows cookies or authentication headers to be included.
Preflight Requests (OPTIONS)
For certain requests, browsers send a preflight request before the actual request.
When Preflight Happens
- Non-simple HTTP methods (PUT, DELETE)
- Custom headers
- Credentialed requests
Preflight Flow
- Browser sends OPTIONS request
- Server responds with allowed rules
- Browser decides whether to proceed
Same-Origin Policy vs CORS
| Aspect | Same-Origin Policy | CORS |
|---|---|---|
| Purpose | Restrict access | Allow controlled access |
| Enforced By | Browser | Browser + Server |
| Default Behavior | Block cross-origin reads | Opt-in permission |
Common CORS Misunderstandings
- CORS errors are browser errors, not server failures
- CORS does not protect servers from attacks
- Disabling CORS in browsers is unsafe
Security Implications
Misconfigured CORS can be dangerous.
- Overly permissive origins expose private APIs
- Allowing credentials with wildcard origins is unsafe
- CORS should be as restrictive as possible
Real-World Example
A React frontend hosted on app.example.com calls an API hosted on api.example.com. The API enables CORS for the frontend origin only, allowing secure communication without exposing the API publicly.
Interview-Friendly Summary
The same-origin policy protects users by isolating websites. CORS provides a safe, explicit way to relax that isolation when cross-origin communication is required. Together, they form a critical foundation of browser security and modern web architecture.