Q018: CORS and Browser Security Boundaries

What Interviewers Want To Evaluate

This question tests whether you understand why browsers block some cross-origin requests and why the fix usually belongs on the server. Interviewers want the same-origin policy, CORS, preflight requests, credentials, cookies, custom headers, and the difference between browser enforcement and API authentication.

For senior roles, the strongest answer explains the security boundary clearly and avoids treating CORS as a frontend-only error.

Short Interview Answer

CORS is a browser security mechanism that lets a server explicitly say which origins are allowed to read cross-origin responses. The browser enforces the rule. Simple requests may go directly, while non-simple requests trigger a preflight OPTIONS request. The server must return headers like Access-Control-Allow-Origin, Access-Control-Allow-Methods, and Access-Control-Allow-Headers. If credentials are included, the server must allow a specific origin and Access-Control-Allow-Credentials: true.

Detailed Interview Answer

The same-origin policy prevents a script from one origin from freely reading sensitive responses from another origin. Without it, a malicious site could make a user's browser request private data from another site where the user is already logged in, then read the response.

CORS gives servers a controlled opt-in. The server can allow selected origins to read responses. The browser still sends some requests, but it blocks JavaScript from reading the response unless the CORS policy permits it.

This is why CORS is not the same as authentication. CORS decides whether browser JavaScript can read a response. Authentication decides whether the requester is allowed to access the resource.

Deep Technical Explanation

A request involves three identities:

page origin
target origin
request credentials or auth headers

If the request is non-simple, the browser sends a preflight request first. Non-simple usually means custom headers, methods like PUT or DELETE, or certain content types.

Important Headers

Access-Control-Allow-Origin tells the browser which origin may read the response. Access-Control-Allow-Methods lists allowed methods. Access-Control-Allow-Headers lists request headers allowed by the preflight. Access-Control-Allow-Credentials allows cookies or HTTP credentials to be included when the client uses credentials mode.

Vary: Origin matters when the server reflects origins and responses pass through shared caches. Without it, a cache might reuse a response with the wrong CORS headers.

Code Example

fetch("https://api.example.com/account", {
  method: "GET",
  credentials: "include",
});

For this to be readable by the page, the API response must use a specific allowed origin, not *, when credentials are included.

Access-Control-Allow-Origin: https://app.example.com
Access-Control-Allow-Credentials: true
Vary: Origin

Internal Working

The browser owns enforcement. Server-to-server requests are not blocked by browser CORS because they do not run inside the browser's origin model. That is why a request may work from Postman or a backend service while failing in the browser.

Preflight responses can be cached with Access-Control-Max-Age, reducing repeated OPTIONS requests.

Architecture Discussion

Frontend architecture should avoid random cross-origin calls from the browser when a backend-for-frontend can provide a cleaner boundary. A BFF can centralize auth, secrets, rate limiting, and response shaping.

For public APIs, define an explicit allowlist of origins. Avoid reflecting arbitrary origins without validation.

Trade-Offs

CORS allows browser-based integrations without giving every site read access. The trade-off is operational complexity: local development origins, preview URLs, credentials, custom headers, and CDN caching all need consistent configuration.

Common Mistakes

A common mistake is trying to fix CORS only in React code. The browser is blocking the response because the server did not provide the right policy.

Another mistake is using Access-Control-Allow-Origin: * with credentials. Browsers reject that combination.

Real Production Story

A feature may work in development and fail in production because the API allows http://localhost:3000 but not the deployed origin. Preview deployments can create the same issue if every preview URL is a new origin.

Enterprise Example

In a multi-tenant SaaS app, the platform may allow each customer to configure a custom domain. The API CORS layer must understand trusted customer domains, credentials, and cache behavior without opening responses to arbitrary origins.

Performance Discussion

Preflight requests add latency, especially on high-latency networks. Reduce unnecessary custom headers, use simple requests when appropriate, and cache preflight responses safely.

Security Considerations

CORS does not protect an API from non-browser clients. Servers must still authenticate and authorize every sensitive request. CORS also does not stop CSRF by itself; cookie-based flows still need SameSite, CSRF tokens, or equivalent protections.

Senior Engineer Perspective

A senior engineer should say exactly where the fix belongs: client request mode, server CORS headers, auth policy, CDN cache behavior, or architecture boundary.

Lead Engineer Perspective

A lead should define allowed origins by environment, preview deployment policy, credential rules, and runbooks for debugging CORS failures.

Whiteboard Explanation

Draw the browser as the security enforcer between the page and the API. Show preflight, allow headers, actual request, and readable response.

Revision Notes

CORS is browser-enforced permission for JavaScript to read cross-origin responses. It is not API authentication. Credentialed requests need a specific allowed origin and Access-Control-Allow-Credentials: true.

Key Takeaways

When CORS fails, ask which origin made the request, which API origin received it, whether credentials were included, and which headers the server returned.

Related Topics

• Same-origin policy
• Cookies and SameSite
• CSRF
• Fetch API
• CDN caching
• Backend-for-frontend

Practice Exercise

Explain why a request works in Postman but fails in Chrome. Then design CORS rules for local development, preview deployments, and production.

Follow-Up Questions

1. What is the same-origin policy?
2. What problem does CORS solve?
3. What is a preflight request?
4. Which requests trigger preflight?
5. Why cannot * be used with credentials?
6. What does Vary: Origin protect?
7. Is CORS authentication?
8. Why does Postman bypass browser CORS?
9. How do cookies interact with CORS?
10. How would you debug a production CORS issue?

Things Interviewers Hate Hearing

"Just add CORS on frontend" is the wrong mental model. The server grants permission and the browser enforces it.

How I Would Answer This In A Real Interview

I would start with the same-origin policy: browser JavaScript cannot freely read responses from other origins. CORS is the server's opt-in mechanism that tells the browser which origins may read a cross-origin response.

Then I would explain preflight, credentials, and server headers. I would also separate CORS from authentication and mention that server-to-server calls do not have browser CORS enforcement.