Same-Origin Policy and CORS: How Browsers Enforce Web Security Boundaries

The fundamental question in web security is what stops a script on one website from reading sensitive information, such as a bank balance, from another site where the user is logged in. Technically nothing prevents the request itself from being sent, because the browser would attach the user’s cookies, making the request appear authenticated. However, the Same-Origin Policy built into every browser blocks the script from reading the response, thereby protecting user data across different sites.

An origin consists of exactly three components: protocol, domain, and port. Two URLs belong to the same origin only when all three match. For example, https://shop.ru/catalog and https://shop.ru/cart share the same origin, while http://shop.ru and https://shop.ru are treated as different origins. Even subdomains such as https://api.shop.ru constitute a separate origin from https://shop.ru, which frequently surprises developers building front-end applications that call their own APIs.

The policy states that code executing in one origin cannot read data from another origin. It does not prohibit loading foreign resources; it only prevents programmatic reading of their content. Images, fonts, analytics scripts, and embedded videos from other origins load and display normally. Attempting to draw such an image onto a <canvas> element and read its pixels is blocked. Similarly, an <iframe> can display a third-party page, yet JavaScript cannot inspect or extract data from that frame.

Foreign scripts loaded via <script> tags execute with the privileges of the including page because they become part of that origin’s code rather than remaining external data. This behavior enables libraries such as jQuery from CDNs but also introduces risk if the CDN is compromised. Developers therefore often host critical libraries themselves or apply subresource integrity hashes.

When an application must read data from another origin, for instance retrieving weather information from a public API, the Cross-Origin Resource Sharing (CORS) mechanism provides a controlled exception. The target server decides whether to allow the read by returning the header Access-Control-Allow-Origin. A value of * permits any origin, while a specific domain restricts access to that single origin. Without this header the browser discards the response before handing it to the calling script.

CORS operates exclusively inside the browser and does not protect servers against requests issued from tools such as curl or from other servers. Authentication and authorization checks on the server side remain the only effective controls for sensitive data. Even when a request is blocked by CORS, the request itself may still have reached the server and triggered side effects if it was a state-changing operation.

Browsers classify cross-origin requests as simple or non-simple. Simple requests (GET or POST with standard content types) are sent immediately. Non-simple requests trigger a preliminary OPTIONS preflight request so the server can declare which methods and headers it accepts before the actual request is issued.