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.
What does the "Same-Origin Policy Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to same-origin policy vocabulary through 5 multiple-choice questions, each built from realistic workplace sentences rather than abstract definitions.
Is this vocabulary exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is completely free — no account, sign-up, or payment required.
How many questions does this exercise have?
This exercise has 5 questions. Each one shows a real-world sentence or scenario with multiple-choice options and an explanation once you answer.
What happens after I answer a question?
You'll see immediate feedback showing whether your answer was correct, along with a short explanation of why — then a button to move to the next question, and a full results screen at the end.
Can I retry the exercise if I get questions wrong?
Yes. Once you reach the results screen, click "Try again" to reset your answers and go through the exercise from the start as many times as you like.
Do I need to create an account to take this exercise?
No account is needed. Your answers are scored in your browser during the session — nothing is saved to a server, so you can jump straight in.
Is my progress saved if I leave the page?
No — progress within an exercise resets if you navigate away or reload. Each exercise is short enough to complete in a few minutes in one sitting.
Are these vocabulary exercises connected to other topics?
Yes — this module shares real-world context with 11 other vocabulary modules. See "Related vocabulary" below to keep building a connected skill set.
How is this different from reading a glossary or blog article?
Exercises like this one are active recall drills — you have to choose the correct term or phrasing yourself, which builds retention faster than passively reading a definition.
Where can I find more vocabulary exercises?
Browse the full Vocabulary exercises hub for hundreds of modules covering Agile, DevOps, security, databases, architecture, and more — organised by IT role and skill.