CORS: when the browser allows reading from another origin

Useful to know

In web addresses, the origin is determined by a scheme, domain, and port. Changing any of these parts can put two addresses in different origins. When JavaScript in a page wants to read a response from another origin, the browser applies access rules. CORS is the mechanism by which the server can indicate how such a response should be shared with the page code. It uses HTTP headers and is involved in the operation of the browser. [1]

The Access-Control-Allow-Origin header indicates for which origin the answer can be shared. [2] It is important to distinguish two actions: the server processes a request and the browser code is allowed to read its response. CORS is not a universal ban on all other programs connecting to the server. Therefore, the access design cannot end with this header. The protection of the data itself must be viewed separately from the permission to read in the browser.

Let's look at a fictional library catalog. The public site is at one address, and the search service is at another. The team expects the page to display results from this service. If the link does not work, it is useful to record the starting address, the target address, and the actual origin of the page. This small inventory prevents guesswork by saying "the domain looks almost the same". For the technical rule, the exact value is important, not the visual similarity between the names.

In some of the requests, the browser first sends a preliminary check called preflight. It communicates what method and headers are provided for the actual request. The server responds to whether this is allowed. [1] When querying with credentials, there are additional limitations: the asterisk in Access-Control-Allow-Origin does not replace a specific allowed origin for sharing such a response. [2] This is why permissions are described according to actual use, instead of mechanically placing the widest viewable value.

For a practical test, it is good to use the page itself, which will execute the request. Successfully opening the address in a separate section does not prove that the code of another origin will be able to read the answer. In a learning example, we can compare allowed and unresolved origins and record what the application sees in each case. Test data is used so that the diagnosis does not change real records.

A good explanation of the setting includes three specific things: which page needs the answer, from which address it gets it, and why this sharing is necessary. It is then checked that the rule matches these needs. Thus, CORS remains an understandable contract for browser access. It doesn't have to be assumed to be a cryptic error, nor does it need to expand indefinitely just to make the message disappear from the console.