Build fluency in the vocabulary of a browser asking permission before a cross-origin request.
0 / 5 completed
1 / 5
At standup, a dev mentions the browser automatically sending an OPTIONS request to the server before the actual cross-origin request, to ask permission for a method or header the server hasn't already allowlisted. What is this OPTIONS request called?
A CORS preflight request is the OPTIONS request the browser automatically sends before the actual cross-origin request, asking the server for permission to use a method or header that isn't already covered by CORS's simple-request rules. A same-origin request never triggers this at all, since CORS only governs cross-origin calls in the first place. This preflight check is what lets the browser confirm a server actually consents to a potentially sensitive cross-origin request before it's allowed to happen.
2 / 5
During a design review, the team wants the server's CORS response to echo back a specific origin drawn from a trusted allowlist, rather than always sending a wildcard Access-Control-Allow-Origin value alongside credentialed requests. Which capability supports this?
An origin allowlist that the server checks against before echoing that exact origin back in the response header lets the server grant CORS access only to origins it actually trusts, while still supporting credentialed requests, which browsers refuse to allow alongside a wildcard origin. Always responding with a wildcard value regardless of the requesting origin either breaks credentialed requests outright or, if misconfigured, opens the door to an untrusted origin. This origin-specific allowlisting is what keeps a credentialed cross-origin API narrowly scoped to origins it genuinely trusts.
3 / 5
In a code review, a dev notices a server configured to respond with Access-Control-Allow-Origin set to the literal wildcard '*' while also setting Access-Control-Allow-Credentials to true. What does this represent?
This is an invalid, insecure CORS configuration that modern browsers actually reject for credentialed requests specifically because combining a wildcard origin with credentials would let any origin on the internet make an authenticated request on a user's behalf. A CORS preflight request describes the OPTIONS mechanism itself, not this specific header misconfiguration. This combination is a red flag a reviewer should catch, since even where a particular client happens to tolerate it, it signals the server's CORS policy hasn't been scoped to a genuine allowlist.
4 / 5
An incident report shows an attacker's site was able to make an authenticated cross-origin request against a production API and read the response, because the API's CORS configuration echoed back any origin at all instead of checking against a trusted allowlist. What practice would prevent this?
Validating the requesting origin against an explicit allowlist before echoing it back ensures only a genuinely trusted origin receives permission to make a credentialed cross-origin request. Continuing to echo back any requesting origin at all, with no allowlist check, is exactly what let the attacker's site read authenticated responses in this incident. This allowlist validation is a mandatory control for any API that needs to support credentialed cross-origin requests from more than one trusted frontend.
5 / 5
During a PR review, a teammate asks why the team validates the requesting origin against an explicit allowlist instead of just always responding with a wildcard Access-Control-Allow-Origin to keep every frontend working with the least configuration effort. What is the reasoning?
A wildcard origin either breaks credentialed requests outright, since browsers refuse to pair a wildcard with credentials, or, if the server layers in some workaround, ends up letting any origin on the internet make an authenticated request on a user's behalf. An explicit allowlist limits that access to origins the team actually trusts, closing off exactly that risk. The tradeoff is the ongoing maintenance of keeping the allowlist current as new legitimate frontends are added or retired.
What does the "CORS Preflight Vocabulary" vocabulary exercise cover?
This exercise tests real IT vocabulary related to cors preflight 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.