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.