When two websites are open in neighboring tabs, they may look equally available to you. To the browser, however, they belong to separate security spaces. The same-origin policy is one of the web’s foundational rules for keeping a page from freely reading data that belongs to another site.
It works quietly in the background every time you use webmail, online banking, cloud storage, or any service where private information appears after sign-in.
What counts as an origin?
An origin is defined by three parts of a URL: the scheme, host, and port. In simple terms, the browser asks whether the protocol, domain, and network port match.
- https://example.com and https://example.com/account share an origin.
- http://example.com and https://example.com do not, because the scheme differs.
- https://shop.example.com and https://example.com do not, because the host differs.
- Two otherwise identical URLs using different explicit ports do not share an origin.
This precise definition gives the browser a consistent boundary. The MDN same-origin policy reference documents the model and its important edge cases.
What the policy prevents
Imagine visiting an untrusted page while you are signed in to another service. Without an origin boundary, the untrusted page might read the contents of your inbox, account dashboard, or private documents simply because the browser can reach both sites. The same-origin policy prevents scripts in one origin from directly inspecting most sensitive resources and document contents from another.
The rule mainly limits cross-origin reads and script access. The web still needs links, images, forms, fonts, videos, and embedded services, so some cross-origin writes and embeds are possible. What a page may request is not always the same as what its scripts may read.
Cookies use related but different rules
Cookies often enter this discussion, but their boundaries are not identical to the origin model. Domain, path, Secure, HttpOnly, and SameSite attributes affect when a cookie is stored, sent, or exposed to script. A cookie can be unavailable to JavaScript because it is HttpOnly while still being sent with an appropriate request.
SameSite also uses the concept of a “site,” which is broader than an origin in important ways. That is why privacy and security explanations should not treat same-origin and same-site as interchangeable. Our guide to third-party cookies explores the practical tracking side of these rules.
How CORS enables controlled sharing
Modern applications often need to request data from a separate API origin. Cross-Origin Resource Sharing, or CORS, lets the server explicitly state which origins may read a response. The browser enforces that response policy for frontend JavaScript.
For some requests, the browser first sends a preflight request to ask which methods and headers the server accepts. The server can approve a specific origin, limited methods, and selected headers instead of opening access broadly. The MDN CORS guide explains the headers and preflight process.
CORS is not a substitute for authentication or authorization. A server must still verify who the requester is and what that account may do. CORS tells the browser whether a page may read a cross-origin response; it does not turn a public endpoint into a private one.
Safe communication between windows
Separate origins sometimes need to coordinate. A sign-in popup, payment frame, or embedded tool may use the web platform’s messaging features to exchange a limited piece of information. With postMessage, the receiving page should verify the sender’s origin and validate the message structure before acting.
Using a wildcard destination or trusting every incoming message discards much of the protection the boundary provides. Good integrations define exactly which origin may participate and exactly what data is expected.
Same-origin policy, sandboxing, and site isolation
These terms describe different layers. The same-origin policy is a web security rule that restricts how documents and scripts interact. Browser sandboxing limits what a compromised renderer process can do to the operating system. Site isolation can place sites into separate processes to make cross-site data harder to reach even after certain vulnerabilities.
The layers reinforce one another, but none makes the others unnecessary. Read our explanation of browser sandboxing for a closer look at process containment.
Why you may see a CORS error
A CORS message in developer tools usually means a page attempted to read a response from another origin without matching permission from that server. It is not something a visitor should “fix” by disabling browser security. For site owners, the correction belongs in the API configuration: approve the required origins and methods narrowly, then test credential handling carefully.
Browser extensions can have elevated capabilities when users grant them broad host access, which is one reason extension permissions deserve close review. Ordinary website permission prompts for the camera, location, or notifications are separate again. See our browser permissions guide for the user-facing controls.
What this means for everyday browsing
- Keep your browser updated; origin enforcement depends on a large, evolving security engine.
- Do not disable web security flags to make an ordinary site work.
- Review extensions that request access to read and change data on many websites.
- Check the full domain before signing in, because lookalike sites have their own origin.
- Treat unexpected login frames and popups carefully, even when they resemble a familiar service.
The same-origin policy is valuable precisely because it is mostly invisible. It gives every website a defined neighborhood and requires deliberate, constrained mechanisms for crossing the boundary. That separation allows the open web to remain connected without making every open page equally trusted.
Browse with more intention
Noorani brings prayer times, Qibla, tracker blocking, and privacy into one calm desktop browser built for how Muslims live online.