Why is the synchronizer token pattern preferred over the origin header check to prevent CSRF

Simply put

• The Origin header is not sent for same-origin requests by all browsers.
• Current bugs in popular browsers mean that the Origin header is not sent for POST requests, which makes this approach less-than-useless since state changing requests should always use POST above GET.

This would make for complex logic when implementing CSRF protection.

That is:

Lack of Origin header = Old browser/bug OR
Lack of Origin header = Same Origin
Origin header matches domain = Same Origin
Origin header does not match = CSRF attack

As you can see, it is not possible to distinguish between old or buggy browsers possibly making CSRF attacks and legitimate current browser requests. You could add browser detection, but then the logic gets more messy. Complexity tends to reduce security.

This of course, could be patched in a browser update. However, then your application would be incompatible with older versions of the browser.

Much simpler would be to generate a token and send that with each request outside of the cookie mechanism.

It's mostly due to history. People have been aware of CSRF since the early 2000's, before the Origin header had been invented. The concept of "token in a hidden field" provided sites an immediate way to fix the flaw, without waiting for browsers to update. While the mechanism is a little messy, it turns out it is possible for frameworks to provide this functionality automatically, with little input from application developers. Notably, .Net included this from the start with EVENTVALIDATION/VIEWSTATE, and it is relatively rare for .Net applications to have CSRF flaws.

When CSRF was first taken seriously, some people proposed checking the Referer header to fix the flaw. It is widely known that the Referer header is easy to spoof, but this idea is not as silly as it seems. When an attacker makes a direct connection to a web server, it is easy to spoof the Referer header. However, in a CSRF attack, the attacker is not making a direct connection; the victim's web browser is making the connection, and the attacker cannot readily control the Referer header. However, this approach turns out still to be flawed. Older versions of Flash allowed an attacker free control of the Referer header in a CSRF attack scenario. Also, some users disable the Referer header for privacy reasons, which a web site would mistake for a CSRF attack.

The Origin header has been developed as a more secure replacement for the Referer header. In many ways, it is a much neater solution to CSRF, and it avoids the overhead of managing the tokens. Some applications - particularly single page applications - use the Origin header as the only CSRF protection and are completely secure. However, this is the exception rather than the rule. The synchroniser pattern is well understood, widely supported by frameworks, and has no known weaknesses.

Edit - Silverlightfox informs me that the following is not true. See his answer for more info.

Ultimately I think OWASP are being a little backward in their advice. In 2015 they should be advising Origin header checks as the primary control, with the synchroniser pattern as a legacy alternative.