The same-origin policy

The same-origin policy stops script from one origin from freely reading protected data belonging to another origin.

Imagine visiting evil.example while already signed in to a bank. Your browser may attach bank cookies to a request sent to the bank, but the malicious page must not be allowed to read the account response. The read boundary is the essential protection.

The policy is more precise than “cross-origin requests are blocked.” Browsers permit many cross-origin actions:

• an <img> can display an image from another origin
• a <form> can submit to another origin
• a page can link to or embed another origin
• fetch() can send some requests even when script cannot read the response

Controlled exceptions make legitimate applications possible. CORS response headers let a server grant selected origins access to a response. window.postMessage() lets cooperating windows exchange messages, but the sender should use a specific target origin and the receiver must validate event.origin and the message data.

Try fetching an API from the Console on a different origin and inspect both places:

1. The Network panel shows whether a request was sent and what response arrived.
2. The Console shows whether the page’s script was allowed to use that response.

This separates a network failure from a browser access decision. Do not “fix” a CORS error by reflecting every origin or disabling checks. Configure the server to authorize only the origins, methods, and credentials the application actually needs.