Few pairs of security terms get confused as often as these two. They look alike, they both involve requests between different origins, and people routinely reach for one when they mean the other. But they are not two versions of the same thing. One is a browser permission system you configure; the other is an attack you have to defend against. Getting them straight is the first step to handling both correctly.
CORS: a permission system
Cross-Origin Resource Sharing is a rule the browser enforces about which other origins are allowed to read responses from your API. By default the browser stops a page on one origin from reading responses from another, and CORS is how your server grants exceptions, for example letting your own frontend on one domain call your API on another. It is a setting. The danger is setting it too wide, like a wildcard origin with credentials, which lets any site read your API as your user. Details in CORS misconfiguration.
Want to see exactly what Prbl flags? Watch it scan a demo app, no repo or account needed.
See a live scan →CSRF: an attack
Cross-Site Request Forgery is not a setting; it is a thing an attacker does. Another site causes a logged-in user's browser to send a request to your app, and because the browser attaches the session cookie automatically, your server treats it as legitimate and acts on it, changing an email, making a transfer. You defend against it with sameSite cookies and a CSRF token. Details in the broader picture and specifically in what CSRF is.
The trap: CORS does not stop CSRF
Here is the misunderstanding that causes real bugs. People assume a strict CORS policy protects them from CSRF. It does not. CORS controls whether a script can read your response. A CSRF attack does not care about reading the response; it only needs the request to happen and have an effect. The browser still sends it, your server still acts on it, and the attacker never needed to read anything. So you cannot rely on CORS for CSRF protection; they solve different problems.
What each one needs
- CORS: allowlist the specific origins your own frontend uses; never pair a wildcard origin with credentials. Fix for a CORS wildcard.
- CSRF: if you use cookie-based auth, set sameSite and require a CSRF token on state-changing requests. Fix for missing CSRF protection.
Frequently asked questions
What is the one-sentence difference?
CORS is a browser rule about which other origins are allowed to read responses from your API; CSRF is an attack where another site makes a logged-in user's browser send a request to your app. CORS is a permission system you configure; CSRF is a threat you defend against. They both involve cross-origin requests, which is why they get confused, but one is a setting and the other is an attack.
Does a strict CORS policy protect me from CSRF?
No, and this is the most common misunderstanding. CORS controls whether a script can read your response, but a CSRF attack does not need to read the response; it just needs the request to happen and have an effect, like changing an email. The browser still sends the request and your server still acts on it. So a locked-down CORS policy does not stop CSRF; you need sameSite cookies and a CSRF token for that.
Which one do I actually need to worry about?
Both, for different reasons. Misconfigured CORS, especially a wildcard origin with credentials, lets other sites read your API responses as your user. Missing CSRF protection lets other sites trigger state-changing actions as your user. If your app uses cookie-based auth, you need CSRF defenses; if it exposes an API meant only for your own frontend, you need a correct CORS policy. Most apps need both handled.
Do bearer-token APIs need CSRF protection?
Generally no. CSRF relies on the browser automatically attaching credentials, which is how cookies work. An API authenticated with a bearer token in a header is not sent automatically by the browser, so an attacker's page cannot include it, and the classic CSRF attack does not apply. You still need a correct CORS policy for such an API, but the CSRF token is a cookie-auth concern.
Check both in your app
A scan flags a permissive CORS policy in what your app serves, and reviewing for CSRF is part of securing a cookie-authenticated app. Run a free scan and see how your app handles cross-origin access.