The Same-Origin Policy is a critical browser security mechanism that restricts how a document or script loaded from one origin can interact with resources from other origins. It helps prevent malicious sites from reading sensitive data from other websites. The policy considers two URLs to have the same origin if they share the same protocol, host, and port number.
The same-origin policy (SOP) is the browser's foundational isolation rule. It treats two URLs as the same origin only when they share the same scheme, host, and port, so https://shop.example:443 and http://shop.example or https://api.example are different origins. Under SOP, a script running on one origin may load some cross-origin resources (images, scripts, styles) but cannot read the responses, inspect another origin's DOM, or reach its cookies, localStorage, and IndexedDB. The policy is enforced by the browser itself, not the server, and it applies per origin rather than per page. Without it, any tab you opened could silently read your webmail or bank session in another tab.
SOP is what stops a malicious site from scripting your logged-in sessions elsewhere. Because browsers attach your cookies to requests automatically, a page could otherwise issue a fetch to your bank and read the account balance out of the response. SOP blocks that read, which is why cross-site request forgery and cross-origin data theft are constrained. It is not absolute: it governs reading, not sending, so state-changing requests can still fire, and misconfigured CORS, permissive postMessage handlers, or XSS running inside the trusted origin all bypass it. SOP is a boundary between origins, not a defense against code that already executes within your own origin.
Treat SOP as a default to preserve, not an obstacle to route around. When you genuinely need cross-origin access, use CORS with a tight allowlist instead of reflecting arbitrary origins or wildcarding credentialed endpoints. Validate the origin of every postMessage event before acting on it, scope cookies carefully, and keep authentication tokens out of localStorage where any same-origin script can read them. The hardest gap to close is a script that runs inside your own origin, since SOP grants it full trust. Monitoring what your third-party scripts actually do at runtime, which is the core of client-side security, is how you catch abuse of that inherited trust.
No. SOP restricts reading cross-origin responses, not issuing the requests. A page can still send a request to another origin, and the browser attaches your cookies. SOP simply prevents the sending page from reading what comes back, which is why CSRF defenses like SameSite cookies and tokens remain necessary.
No. app.example.com and api.example.com are different origins because the host differs, so SOP isolates them by default. Related sites can relax some interactions through CORS headers or, in narrow legacy cases, document.domain, but browsers increasingly restrict those loopholes in favor of explicit CORS.
We answer client-side security questions every day. Bring yours.