Browser boundaries: origins, CORS, and CSRF

A browser has your bank open in one tab and a recipe in another. What stops the recipe page from reading the bank? The answer begins with origin boundaries, but does not end there.

Origin: In the common web model, a combination of scheme, host, and port used as a browser security boundary.

An origin is an address boundary

An origin combines scheme, host, and port. Two URLs can belong to different origins even when a person thinks of them as one website. A site is a different concept used by cookie rules; do not treat same-site and same-origin as synonyms.

The same-origin policy restricts many cross-origin interactions, especially reading another origin’s data from scripts. It is not a rule saying that browsers can never send cross-origin requests. Navigation, form submission, images, and other mechanisms have their own behavior.

CORS shares responses deliberately

Cross-Origin Resource Sharing lets a server tell the browser which origins may read a response. Some requests require a preflight permission check before the actual request; others may be sent without it. A CORS error visible to JavaScript therefore does not by itself prove that no request reached the server.

CORS is enforced by browsers. It cannot authenticate a caller or replace API authorization, because other clients are not bound by the browser’s same-origin policy.

Protect changes, not just reads

For a cookie-authenticated action such as changing a delivery address, the server needs protection against unwanted cross-site requests. Appropriate anti-CSRF tokens, origin checks, and cookie settings can help, depending on the application. Safe methods should not perform surprising state changes.

Keep your questions separate: is this caller authenticated, may this caller do this, and does this request represent an intended action? Encryption protects transport, not these business decisions.

Worked review: name the blocked stage

Consider a fictional shopping application and its separately hosted preview. The records below are supplied design observations. They describe browser decisions without asking you to construct or send any request.

• B1: The profile and orders pages use HTTPS, host shop.example and effective port 443. Their paths differ. The preview uses the same scheme and host but port 8443.
• B2: An evaluation record confirms that a request from the preview reached the service. The browser then refused the preview script access to the response because the CORS policy did not permit it. No business-effect record is included.
• B3: A different, explicitly approved origin is allowed to read certain API responses. The service has customer accounts with different order permissions.
• B4: The address-change design checks a valid cookie session and order ownership. It treats the cookie’s presence as sufficient evidence of intended workflow; no separate protection for unwanted cross-site changes is documented.

PredictCan B2 be summarized as “the browser blocked the operation, so the server did nothing”?

No. The server receipt is explicit; the blocked stage was the script’s access to the response. The packet does not establish whether the service changed anything. A preflight rejection can prevent an actual request in other cases, but that is not what B2 records.

Keep the server’s decisions separate

B1 illustrates why a familiar hostname does not settle origin identity. The two ordinary pages share an origin despite different paths. The preview does not, because its effective port differs. This comparison says nothing by itself about account identity or order permission.

For B3, a precise CORS allowlist is useful for deliberate browser sharing. It does not authenticate every client or express which order belongs to which account. An allowed browser origin can contain several users, and the server must preserve the relevant user-resource decision.

B4 needs an explicit intended-workflow requirement in addition to authentication and authorization. Appropriate anti-CSRF tokens, validated origin information and suitable cookie policies can contribute, with their application-specific assumptions documented. None should be described as proof of every human intention or a replacement for the order check.

Model review note: verify the three decisions independently: whether sending occurred, whether a script could read, and whether the server authorized the particular change through the expected workflow. State the missing evidence rather than using one generic “blocked” label. Include legitimate address changes in acceptance evidence so a blanket denial cannot masquerade as a usable correction.

EXPLORE THE CONCEPT

Which boundary is doing the work?

Select a claim and see what it really establishes.

A CORS error appears

A script cannot read the response under the current policy. The request may still have reached the server.

The API checks object permissions

The server evaluates whether this identity may act on this object, independently of browser CORS behavior.

A CSRF token is validated

The server has an additional signal about the request’s origin in the intended workflow. Authorization remains necessary.

A simplified learning model. It connects to no systems and uses no real data.

Turn the idea into a decision

Avoid the phrase “the browser blocked it” without saying whether it blocked sending, reading, or a particular operation. That precision changes how you evaluate a design.