CORS vs CSRF

Essentially, CORS and CSRF works based on using existing tokens or cookies on a user browser to make request to the target address where these credential can be used. The difference is that CORS (enforced by web browsers) is a defense mechanism to defend against Javascript execution on sensitive data, while CSRF is an attack that attempts to invoke a state change.

	CORS	CSRF
Scenario	A malicious website attempts to exploit the trust from the browser to use the existing cookies for a target address (eg. bank.com, admin.target.com) to retrieve sensitive data.	A malicious website attempts to exploit the trust from the browser to use the existing cookies for a target address (eg. bank.com, admin.target.com) to send a request to that target address to cause a state change or perform unintended actions
Relies on	Misconfigured or overly permissive Access-Control-Allow-Origin response headers from server	Missing CSRF token or SameSite cookie attributes
Purpose of attack	Steal sensitive data from a target resource, that can be exfiltrated via Javascript	Trick a server into performing an action on behalf of the real authenticated user
Browser defense mechanism	Allow requests, but blocks Javascript from processing the response (eg. to exfiltrate data).	CSRF protection is not enforced on the client side. The browser automatically sends authenticated requests with cookies, regardless of origin.
Server defense mechanism	Properly configured Access-Control-Allow-Origin headers, to explicitly allow or deny which origins can read responses.	Server validates the CSRF token to ensure that it matches the one generated for the client. Only the real client-side code will have the valid CSRF token.
Effects of a successful attack	Sensitive data exposure	Unintended actions taken on behalf of a user (eg. transfer money, update passwords, etc.)

Note on CORS

CORS is enforced by the browser to restrict Javascript on web pages from reading responses from cross-origin requests, unless explicitly allowed by the server's Access-Control-Allow-Origin header. However, CORS does not prevent any other clients, such as cURL, postman or server-side scripts implemented in programming languages from making requests and reading the data.

For example, a server (valid-site.com) exposes data via an API that is expected to only be consumed by pages from the same origin. If a website from an unauthorized origin (not-allowed.com) attempts to fetch data from that API, the browser will allow the request but block the unauthorized site’s Javascript from accessing the response.

Nonetheless, any other non-browser clients can still freely request and read the API data without any restrictions, given that it is publicly accessible and does not require any authentication.

CORS primarily protects authenticated browser-based requests, to ensure that data is not able to be retrieved without the user's permission. CORS enforcement is only relevant in browsers, since browsers automatically include credentials such as cookies in requests.