[devinl]

So from reading this over it sounds like you are enabling an endpoint on your site with both CSRF protection enabled that also sends CORS headers to allow for cross origin ajax calls. This could be a workable solution for cross domain calls on the same subdomain (like a.example.com and b.example.com but not malware.com). Since you can scope cookies to domain suffixes, you can have a csrf cookie that can be read from javascript from a number of subdomains and included in a header but can't be read from other domains. Same origin policy prevents domains from reading cookies not scoped to their domain so this should not have any security issues. Note that if you care about confidentiality, you would have to put your CSRF protection on the GET requests (which is a bit abnormal) with CORS since Access-Control-Allow-Origin allows for reading data cross origin (in addition to making requests).

On the other hand, it seems like https://en.wikipedia.org/wiki/Same-origin_policy#Security_Ap... is flawed and should be fixed. The section seems to be directly describing a CSRF attack and then saying CSRF protections are not effective which doesn't make sense.

[dagobah]

I think https://en.wikipedia.org/wiki/Cross-site_request_forgery#Coo... is flawed too because "Access-Control-Allow-Origin: *" doesn't let browsers send cookies with the request, so any of the CSRF prevention methods shouldn't be broken by it. I was just using "Access-Control-Allow-Origin: malware.com" as an example of a worst case scenario where I still don't think the cookie-to-header method is exploitable, unless I'm missing something. The articles don't give examples or link to sources, so I'm guessing both are slightly wrong. I could try to edit them, but wanted to make sure I wasn't wrong first.