CORS + Cookies + SameSite: Frontend Basics (Why Requests Fail)

CORS is one of the most frustrating “it works locally but fails in prod” topics.

Interviews ask about it because it tests real-world debugging and security basics.

30‑second interview answer

CORS is the browser’s enforcement of the same-origin policy for reading cross-origin responses. The server must allow access via CORS headers (Access-Control-Allow-Origin, etc.). If you send cookies cross-site, you typically need credentials: 'include' on the client and proper server headers + correct cookie attributes (SameSite, Secure). Preflight (OPTIONS) happens for non-simple requests.

Key points

• CORS is server-configured; frontend can’t “fix” it alone.
• Browser may send request but block response from being read.
• Preflight is an OPTIONS permission check.
• Cookies + cross-site require credentials + correct SameSite.

1) Same-origin policy (the root)

Browsers restrict how one origin can read responses from another origin.

Origin = scheme + host + port Examples:

• https://example.com ≠ http://example.com
• https://example.com ≠ https://api.example.com
• https://example.com ≠ https://example.com:444

2) What is CORS?

CORS is a server-driven way to allow cross-origin reads.

The server adds headers like:

• Access-Control-Allow-Origin
• Access-Control-Allow-Methods
• Access-Control-Allow-Headers

If headers don’t match what the browser expects, the browser blocks the response.

3) Simple requests vs preflight

Simple requests

No preflight OPTIONS request if:

• method is GET/HEAD/POST
• and headers are limited to “simple headers”
• and content-type is one of a small set (like application/x-www-form-urlencoded)

Preflight

If you send:

• Authorization header
• Content-Type: application/json
• PUT/DELETE/PATCH

Browser sends an OPTIONS preflight first.

4) Credentials mode (cookies)

If you want cookies cross-site:

• frontend must set credentials: 'include'
• server must set:
  • Access-Control-Allow-Credentials: true
  • Access-Control-Allow-Origin must be a specific origin (not *)

Example:

fetch('https://api.site.com/me', {
  credentials: 'include'
});

5) Cookies + SameSite

SameSite controls when cookies are sent in cross-site contexts.

• SameSite=Lax (default-ish): cookies sent on top-level navigation, not on most cross-site fetches
• SameSite=None; Secure: cookies sent cross-site, but requires HTTPS

If you use cookie-based auth across domains, you often need:

• SameSite=None; Secure

6) Common failure patterns

A) Server uses Access-Control-Allow-Origin: * with credentials

That fails.

If credentials: include, server must return a specific origin.

B) Preflight fails because headers/method not allowed

You’ll see:

• “CORS policy: Request header field Authorization is not allowed...”

Fix on server:

• include Authorization in Access-Control-Allow-Headers

C) Cookies not being sent

Check:

• credentials: 'include'
• SameSite setting
• domain/path
• Secure flag + https

7) Interview Q&A

Q: Does CORS block requests?

• Browser blocks reading the response; the request may still be sent.

Q: Who needs to fix CORS?

• The server (sets headers). Frontend can only configure request mode.

Q: When does preflight happen?

• Non-simple methods/headers, or JSON content-type.

Summary checklist

• I can define origin (scheme+host+port).
• I can explain preflight and when it happens.
• I know CORS is fixed on server.
• I can explain cookies + credentials + SameSite.

Summary

• Same-origin policy is the baseline.
• CORS is server-controlled allowlist via headers.
• Preflight is OPTIONS check for “non-simple” requests.
• Cookies + cross-site require credentials + proper SameSite.