Same-Origin Policy
The same-origin policy is a fundamental browser security mechanism that restricts how documents and scripts from one origin can interact with resources from another origin, preventing malicious sites from accessing data on other sites.
Understanding Same-Origin Policy
The same-origin policy (SOP) is the cornerstone of web security. An origin is defined by the combination of protocol (http/https), host (domain), and port. Two URLs have the same origin only if all three components match. https://example.com and http://example.com are different origins (different protocol). https://example.com and https://api.example.com are different origins (different host).
SOP restricts cross-origin interactions in several ways. JavaScript on one origin cannot read responses from another origin via fetch or XMLHttpRequest (unless CORS headers permit it). A page cannot access the DOM of an iframe from a different origin. Cookies are scoped to their domain and cannot be read by other domains. localStorage is isolated per origin.
Importantly, SOP does not block cross-origin requests — it blocks reading the responses. A page at evil.com can submit a form to bank.com (this is how CSRF works), but it cannot read the response. SOP prevents evil.com from stealing data from bank.com, but it does not prevent evil.com from sending requests to bank.com that trigger actions.
The policy has controlled relaxation mechanisms. CORS allows servers to explicitly permit cross-origin reading. The postMessage API allows controlled communication between windows from different origins. JSONP was a historical workaround that is now considered insecure. document.domain manipulation can loosen SOP within a shared parent domain, though this is being deprecated.
Why This Matters for Vibe-Coded Apps
Vibe coders often encounter the same-origin policy as a confusing error message when their frontend cannot call their backend API. The solution is CORS configuration, not disabling the same-origin policy. AI-generated code sometimes works around SOP issues with overly permissive CORS settings (Access-Control-Allow-Origin: *) that solve the immediate problem but weaken security.
Understanding SOP helps you make better architectural decisions: hosting your frontend and API on the same origin eliminates CORS issues entirely. Using path-based routing (api.example.com/api/ on the same origin as the frontend) instead of subdomain-based separation (api.example.com separate from app.example.com) simplifies both SOP compliance and cookie sharing.
Real-World Examples
Spectre Side-Channel Bypass (2018)
The Spectre CPU vulnerability demonstrated that same-origin isolation could be bypassed at the hardware level. By measuring memory access timing, a malicious script could read data from other origins sharing the same process. This led browsers to implement Site Isolation, running different origins in separate processes.
IE Same-Origin Policy Bypasses
Internet Explorer had numerous SOP bypass vulnerabilities over its lifetime, allowing scripts from one origin to read data from another. These vulnerabilities were heavily exploited in targeted attacks and contributed to the push for more robust origin isolation in modern browsers.
postMessage Origin Validation Failures
The postMessage API allows cross-origin communication, but many applications forget to validate the origin of incoming messages. Attackers embed the target page in an iframe and send malicious postMessage events that the page processes without checking the source, leading to XSS-like attacks.
Frequently Asked Questions
What defines an "origin" in the same-origin policy?
An origin is the combination of scheme (protocol), host (domain), and port. https://example.com:443 and https://example.com are the same origin (443 is the default HTTPS port). But https://example.com and http://example.com are different origins (different scheme). https://example.com and https://api.example.com are different origins (different host). https://example.com and https://example.com:8080 are different origins (different port).
Why does the same-origin policy block my API calls?
When your frontend (e.g., http://localhost:3000) calls your API (e.g., http://localhost:4000), the different port makes them different origins. The browser sends the request but blocks your JavaScript from reading the response unless the API includes CORS headers allowing your frontend's origin. The fix is configuring CORS on your API to permit your frontend origin, not disabling the same-origin policy.
Does same-origin policy apply to images and scripts?
SOP does not prevent loading cross-origin resources — images, scripts, stylesheets, and fonts can be loaded from any origin. What SOP prevents is programmatic reading of cross-origin responses. You can display a cross-origin image but cannot read its pixel data via canvas (unless CORS allows it). You can load a cross-origin script but cannot intercept its source code. This load-but-do-not-read distinction is fundamental to how the web works.
Is SOP being replaced by something better?
SOP is being enhanced, not replaced. Cross-Origin Opener Policy (COOP), Cross-Origin Embedder Policy (COEP), and Cross-Origin Resource Policy (CORP) provide more granular origin isolation. These newer policies address gaps in SOP — particularly around shared processes (Spectre mitigation), cross-origin embedding, and resource access. Together with SOP, they form a comprehensive origin isolation framework for modern browsers.
Is Your App Protected?
VAS automatically scans for vulnerabilities related to same-origin policy and provides detailed remediation guidance. Our scanner targets issues common in AI-generated applications.
Scans from $5, results in minutes. Get actionable fixes tailored to your stack.
Get Starter Scan