I'll start my answer by saying that many people misunderstand the [Same Origin Policy][1] and what [CORS][3] brings to the table.

Some of the up-voted answers already here are stating that the Same Origin Policy prevents cross-site requests, and therefore prevents [CSRF][2]. This is not the case. All the SOP does is prevent the response from being read by another domain (aka origin). This is irrelevant to whether a CSRF attack is successful or not.

The only time the SOP comes into play with CSRF is to prevent any token from being read by a different domain.

All CORS does is relax the SOP when it is active. It does not increase security, it simply allows some exceptions to take place. Some [browsers with partial CORS support][4] allow cross site XHR requests (e.g. IE 10 and earlier), however they do not allow custom headers to be appended. In CORS supported browsers the `Origin` header cannot be set, preventing an attacker from spoofing this.

I mentioned domains were different origins. Origins can also differ by port and protocol when talking about AJAX requests (not so much with cookies).

Finally, all of the above has nothing to do with forged requests coming directly from an attacker, for example with curl. Remember, the attacker needs to use the victim's browser for their attack. They need the browser to automatically send its cookies. This cannot be achieved by a direct curl request as this would only be authenticating the attacker in this type of attack scenario (the category known as "client-side attacks").

The benefit of CORS is that it allows your domain to allow reads from another trusted domain. So if you have `http://data.example.org` you can set response headers to allow `http://site.example.com` to make AJAX requests and retrieve data from your API.

  [1]: https://en.wikipedia.org/wiki/Same-origin_policy
  [2]: https://en.wikipedia.org/wiki/Cross-site_request_forgery
  [3]: https://en.wikipedia.org/wiki/Cross-origin_resource_sharing
  [4]: http://caniuse.com/#search=CORS