Hixie said the position I expressed was a little unclear, so I'd like to clarify briefly:
1) FACT: The HTML5 version of the CSRF-defense header (currently called 'XXX-Origin' as a temporary measure) is specified not to be sent for GET requests. 1.a) FACT: As a result, it does not provide any protection against CSRF attacks on GET-based forms. 1.b) OPINION: I think this is an OK choice and I do not propose changing it. It strikes a decent balance between security and privacy.
2) FACT: Hyperlinks or GET-based forms (which are commonly submitted cross-site) cannot redirect to POST-based forms. 2.a) OPINION: Specially marking Origin in the case of redirects is not necessary to secure a site's off-site links and GET-based forms against CSRF attacks on POST-based forms.
3) FACT: Cross-site form POSTs to untrusted sites are quite rare; and furthermore a man-in-the middle attacker redirecting such a request cannot change the body of the submission. 3.a) OPINION: Defending against CSRF in this rare case is not worth the cost of a second different Origin header, and can be done in any case by the site making such bodies readily distinguishable from its own form post bodies.
4) FACT: Sites vulnerable to XSS could be vulnerable to a man-in-the- middle CSRF as in point 3, but they are owned anyway. 4.a) OPINION: It's not worthwhile to defend XSS-vulnerable sites against CSRF, as no meaningful protection is provided.
CONCLUSION: We should use a single Origin header with the name and semantics of the Access-Control Origin header for both its Access- Control purpose and for redirect defense. The differences in the HTML5 version are not worth the cost of a very similar but subtly different header. And if we ever find the attack in case 3 is more than theoretical, we could add a 'Redirected-Via' header to provide full information.
Regards, Maciej
