[wearhere]

You can trust the browser itself (not application code, but the native code) to issue the appropriate headers. If you could find a way of compromising that, it would be a vulnerability wayyy beyond the scope of our protection.

(Caveat: browsers may not implement the specs completely/bug-free yet, as we cover in our post. But we fully expect they will, and in the meantime our module supports fallbacks. This approach is "skating to where the puck will be".)

Non-browser clients can spoof these headers, but the risk then is DOS, not clients leveraging the user's credentials—which is the primary focus of CSRF protection. It's nice that our method can prevent browser-based DOS attacks, but that's by no means complete DOS protection.

[ubernostrum]

If you could find a way of compromising that

CVE-2011-0696 (the Django version of a bug that did affect several major things) is what happens when you find a way of getting the browser to make a cross-domain request with custom headers.

(the underlying issue there was a combination of a bug in Flash, and the semantics of the HTTP 307 status code)