Does enabling CORS protect you from CSRF?

This is a senior-level trap because the two acronyms sound related and both involve "cross-origin." Many engineers assume CORS is a security wall. In reality CORS relaxes a wall, and it addresses a different problem than CSRF.

What CORS actually does

The same-origin policy normally stops JavaScript on site A from reading the response of a request to site B. CORS is the mechanism by which site B can opt in to letting site A read its responses. So CORS is about relaxing read restrictions, not about blocking requests. A restrictive CORS config simply means other origins cannot read your responses — it does nothing to stop a request from being sent.

Why CSRF doesn't care

A CSRF attack rides on the victim's already-authenticated session. The attacker's page triggers a state-changing request (transfer funds, change email) and the browser automatically attaches the victim's cookies. The attacker never needs to read the response — the damage is done by the side effect. Many such requests (a plain form POST, an image GET) are "simple requests" that don't even trigger a CORS preflight. So CORS, which only governs reading, is irrelevant to the attack. The "stops GET but not POST" distractor misreads how this works entirely.

The actual defenses

• Anti-CSRF tokens — an unpredictable per-session/per-request token the attacker cannot guess.
• SameSite cookies (Lax/Strict) — the browser withholds the cookie on cross-site requests.
• Validating Origin/Referer on state-changing endpoints.

What interviewers look for

A clear "no," the read-versus-send distinction, and the correct mitigations. Confusing CORS with a CSRF defense is a common and revealing mistake.