Learn the vocabulary of a browser's default rule blocking cross-origin reads of a response.
0 / 5 completed
1 / 5
At standup, a dev mentions a browser blocking a script running on one page from reading the response of a request made to a different scheme, host, or port, unless that response explicitly opts in to sharing. What is this browser security rule called?
The same-origin policy is the browser's default rule blocking a script on one page from reading the response of a request made to a different origin, defined as the combination of scheme, host, and port, unless that response explicitly opts in to being shared, typically through CORS headers. A CORS preflight request is the specific OPTIONS mechanism that operates within this policy for certain kinds of cross-origin requests, not the underlying rule itself. This default-deny stance is the foundational browser security boundary that CORS then selectively relaxes for origins that choose to opt in.
2 / 5
During a design review, the team confirms that a script on evil.example cannot read the response of an authenticated request it triggers against bank.example, even though the request itself is sent and the victim's session cookie is attached, because the two sites are different origins. Which capability does the same-origin policy provide here?
The same-origin policy provides preventing the attacker's script from reading sensitive response data back, even though, in some cases, the cross-origin request itself can still be sent with the victim's credentials attached, since the policy specifically restricts which origin is allowed to read the response, not necessarily whether the request can be dispatched at all. This is exactly why CSRF is a distinct, separate concern from the same-origin policy, since a forged request can still cause a side effect even when the attacker's script is blocked from reading back the result. This read-versus-send distinction is a subtle but important part of understanding what the same-origin policy actually protects against.
3 / 5
In a code review, a dev notices a page sets a response header explicitly allowing any origin to read its data, without restricting that permission to a specific trusted set of origins. What does this represent?
This is a same-origin policy relaxation that's broader than necessary, since explicitly allowing any origin to read the response, rather than a specific trusted allowlist, potentially lets an untrusted or even malicious origin access data the same-origin policy would otherwise have kept protected. A CSRF token is an unrelated defense against forged requests, not about relaxing read access across origins. This is exactly why a broad, unrestricted relaxation of the same-origin policy should be reserved for genuinely public data, with anything sensitive scoped down to an explicit, narrow allowlist of trusted origins instead.
4 / 5
An incident report shows a competitor's site was able to read a user's private account data by making a cross-origin request against the API, because the API had relaxed the same-origin policy to allow any origin to read its responses instead of scoping that access to a specific trusted allowlist. What practice would prevent this?
Scoping any relaxation of the same-origin policy to a specific, trusted allowlist of origins ensures only genuinely trusted sites can read the API's responses, closing off exactly the broad exposure that let the competitor's site read private account data in this incident. Continuing to allow any origin at all to read the responses is precisely the overly broad configuration that caused it. This allowlist-scoped relaxation is the standard, necessary discipline whenever an API needs to share data across origins at all, rather than leaving that access wide open by default.
5 / 5
During a PR review, a teammate asks why the team scopes cross-origin data sharing to a specific allowlist instead of just allowing any origin to read the API's responses, since it's simpler to configure and keeps every legitimate frontend working with no extra maintenance. What is the reasoning?
Allowing any origin to read the response removes the same-origin policy's protection entirely for every user of the API, since it grants read access to origins the team has no relationship with, no visibility into, and potentially no ability to trust at all, including an attacker's own page. An allowlist instead limits that access specifically to origins the team has deliberately vetted and trusted, preserving the same-origin policy's protection for everyone else. The tradeoff is the ongoing maintenance of keeping that allowlist accurate as legitimate frontends are added or retired, which is a small, manageable cost compared to the scope of data exposure an unrestricted relaxation invites.