Q254: CORS Preflight Credentials and Cross Origin Requests

What Interviewers Want To Evaluate

Interviewers want to know whether you understand that CORS is a browser enforcement mechanism, not a general server security feature.

They also want to know whether you can debug preflight failures, credential issues, cookies, custom headers, and unsafe cross-origin assumptions.

This topic is common because real frontend teams lose a lot of time to unclear CORS errors.

Short Interview Answer

CORS controls whether browser JavaScript from one origin may read responses from another origin. For non-simple requests, the browser sends a preflight OPTIONS request to ask whether the method, headers, and credentials are allowed. Credentials require Access-Control-Allow-Credentials: true, a specific allowed origin, and correct cookie settings such as SameSite=None; Secure for cross-site cookies. CORS does not authenticate users; it only controls browser read access.

Detailed Interview Answer

CORS stands for Cross-Origin Resource Sharing.

It exists because the browser follows the same-origin policy.

An origin is:

scheme + host + port

These are different origins:

https://app.example.com
https://api.example.com
http://app.example.com
https://app.example.com:8443

The browser can send many cross-origin requests.

The key restriction is whether frontend JavaScript may read the response.

Same-Origin Policy

The same-origin policy protects users by limiting what scripts from one origin can read from another origin.

Without it, a malicious website could load a user's banking page in the background and read private data.

CORS is a controlled relaxation of that rule.

The server says:

this origin may read this kind of response

The browser enforces the decision.

Simple Requests

Some requests do not need preflight.

They must meet strict conditions around method, headers, and content type.

Common simple methods:

GET
HEAD
POST

Simple content types include:

application/x-www-form-urlencoded
multipart/form-data
text/plain

Many modern API requests are not simple because they use JSON content type, authorization headers, or custom headers.

Preflight Requests

A preflight is an OPTIONS request sent before the real request.

The browser asks:

is this origin allowed?
is this method allowed?
are these request headers allowed?
may credentials be included?

Typical preflight headers:

Origin
Access-Control-Request-Method
Access-Control-Request-Headers

The server responds with headers such as:

Access-Control-Allow-Origin
Access-Control-Allow-Methods
Access-Control-Allow-Headers
Access-Control-Allow-Credentials
Access-Control-Max-Age

If the preflight fails, the browser blocks the real request.

Credentials

Credentials can include:

cookies
HTTP authentication
client certificates

With fetch, credentials behavior depends on the option:

fetch(url, { credentials: "include" })

For cross-origin credentialed requests, the server cannot use:

Access-Control-Allow-Origin: *

It must return a specific origin.

It also needs:

Access-Control-Allow-Credentials: true

Cookies and SameSite

Cross-site cookies need careful configuration.

For a cookie to be sent in many cross-site browser contexts, it usually needs:

SameSite=None
Secure

HttpOnly protects the cookie from JavaScript access.

Secure means the cookie is only sent over HTTPS.

SameSite controls cross-site sending behavior.

CORS headers alone do not make cookies work.

The browser cookie policy must also allow them.

CORS Is Not Authentication

CORS does not decide who the user is.

CORS does not replace authorization.

A server must still validate:

session
token
permissions
resource ownership
CSRF protection where needed

A non-browser client can call an endpoint without obeying browser CORS rules.

That is why CORS should not be treated as an API access control system.

It is a browser read-access control.

Debugging CORS

A good debugging flow:

confirm the requesting origin
check whether the request is simple or preflighted
inspect the OPTIONS response
compare requested method with allowed methods
compare requested headers with allowed headers
check credentials mode
check cookie attributes
check whether the response origin is specific or wildcard
check redirects during preflight
check server logs for OPTIONS

Many CORS bugs are actually missing server handling for OPTIONS.

Some are cookie bugs misread as CORS bugs.

Performance Cost

Preflights add round trips.

That can hurt high-frequency API calls.

Ways to reduce cost:

avoid unnecessary custom headers
use Access-Control-Max-Age where safe
batch or coalesce requests
keep APIs same-origin when practical
use an app backend as a trusted proxy when appropriate

Do not remove security checks just to avoid preflight.

Classify the cost and reduce unnecessary complexity.

Interview Example

If asked, "The API works in Postman but fails in the browser. Why?"

Answer:

"Postman is not bound by browser CORS enforcement. I would inspect the browser Network tab, especially the preflight OPTIONS request, and verify that the server returns the correct allowed origin, method, headers, and credential settings."

That explains the difference clearly.

Common Mistakes

Common mistakes include:

using wildcard origin with credentials
forgetting OPTIONS handling
forgetting Access-Control-Allow-Headers
assuming CORS authenticates users
debugging only the real request and ignoring preflight
using cookies without SameSite and Secure settings
forgetting redirects can break preflight
adding custom headers without need

Senior-Level Framing

The senior framing:

"I separate origin policy, authentication, cookie policy, and CSRF risk. CORS decides what browser JavaScript can read. Authentication decides who the user is. Authorization decides what they can do. Cookie and CSRF settings decide when credentials are sent safely."

Practice Prompt

Create a checklist for a cross-origin API call:

frontend origin
API origin
method
headers
body content type
credentials mode
cookie attributes
preflight response
actual response
server auth check

Then explain which part would fail if the API worked in curl but not in the browser.

Final Mental Model

CORS is the browser asking permission to expose a response to JavaScript.

When you remember that, the errors become much easier to reason about.