CORS controls cross-origin sharing; CSRF defenses protect authenticated actions

CORS is a browser mechanism for allowing selected cross-origin interactions. CSRF concerns an unintended action performed with a victim's ambient credentials. The important distinction is sending a request versus allowing another origin's script to read its response.

Some cross-origin requests, including ordinary HTML form submissions, can be sent without a CORS preflight. Consequently, withholding permission to read a response does not by itself protect a state-changing form endpoint.

Illustrative example: an account-preferences form changes a notification setting. If the browser supplies the session cookie and the server accepts the request without an appropriate CSRF defense, response unreadability does not undo the changed setting.

Use a server-validated defense suitable for the application's request model, such as CSRF tokens. For endpoints deliberately requiring non-simple requests, enforce that requirement and keep credentialed CORS permissions narrow. SameSite cookies are an additional layer, not a complete substitute for understanding the flow.

Limit: this is about browser behavior and cookie-style ambient credentials. CORS is neither a general network firewall nor server-to-server authorization. Test the actual accepted methods, content types, and credential behavior instead of inferring protection from one browser console error.