I don't really like the word secure next to CORS; you're relying on the browser to be secure... which it is not.
(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.
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)
They add CORS support to their server resources and get the false assumption that their resources can only ever be retrieved from a web page under their origin or an origin they have trusted (via CORS). They believe that this also protects them from malicious users making requests from outside of a browser (eg. via curl).
CORS is not security, it is loosening of security (namely SOP).
The number of times that I have had someone ask "why can someone access the endpoint via curl? I thought this was protected by CORS" makes me sad.
All I'm saying is that security is a complicated topic. People already misunderstand things like CSRF, CORS, resource protection, etc. And they already get them wrong.
CORS is designed to loosen the security protections added by a same origin policy. It is not designed to increase security.
Piling on CSRF protections is just blurring the use case for CORS. All this is going to do is confuse people more, and more people are going to get it wrong.