Great question—this is such a common point of confusion because both tools touch on cross-origin requests, but they solve entirely distinct problems. Let’s break down why they’re both necessary:

1. CORS controls whether your JS can read cross-origin responses #

The browser’s same-origin policy (SOP) blocks JavaScript from accessing responses to cross-domain requests by default—even if no cookies are involved.

For example: If your app on site-a.com uses fetch() to call an API on site-b.com, the browser will send the request, but it’ll block your JS from reading the response unless site-b.com returns an Access-Control-Allow-Origin header explicitly permitting site-a.com.

CORS isn’t about cookies at all—it’s a way for servers to grant permission to specific external domains to process their response data. Without CORS, cross-origin requests might still go out, but your JS can’t do anything with the results.

2. SameSite=Strict controls whether cookies are sent with cross-origin requests #

This setting exclusively governs cookie behavior: it tells the browser to only attach the cookie to requests that originate from the same site as the cookie’s domain. Cross-domain requests (even those from a subdomain or different protocol) won’t carry the cookie.

But here’s the key: SameSite=Strict doesn’t prevent the cross-origin request from being sent—it just strips the cookie. If site-b.com hasn’t set CORS headers allowing site-a.com, your JS still can’t read the response, even if the request was sent without a cookie.

3. They target different security threats #

• CORS mitigates unauthorized data exfiltration: A malicious site could try to call your banking API to pull account details. Even if the user isn’t logged in (no cookies), without CORS, the browser blocks the malicious JS from accessing the API’s response.
• SameSite=Strict mitigates CSRF attacks: A malicious site could trick a logged-in user into submitting a form to your banking site (e.g., transferring money). Without SameSite=Strict, the browser automatically sends the user’s session cookie, letting the malicious action execute. SameSite=Strict stops the cookie from being sent in this scenario, but it doesn’t block the request itself—CORS would still be needed if the malicious site tried to read the response.

4. Edge cases where both work together #

• Suppose you have a public API that allows cross-origin access (via CORS) but shouldn’t accept authenticated requests from external sites. You’d set CORS headers to allow the domain, but use SameSite=Strict to ensure no session cookies are sent with those cross-origin calls.
• If you do need cross-origin requests to carry cookies (e.g., a subdomain app accessing a parent domain’s API), you’d use SameSite=Lax or SameSite=None (with Secure), and also set Access-Control-Allow-Credentials: true in your CORS headers—both settings are required for the browser to send the cookie and let your JS read the response.

In short: CORS manages access to response data, SameSite manages cookie inclusion. They’re two layers of security that solve different problems, so neither makes the other obsolete.

内容的提问来源于stack exchange，提问作者Balázs Édes