Compatibility of the "Origin" http header for enforcing restrictions

Question

I am building a RESTful JSON api and I am concerned about json data theft and Cross-Site Request Forgery.

A good solution that was created to address both of these problems is the Origin http header. However I am concerned that this method isn't compatible with all modern browsers. Is this a valid concern? Is the Origin http header useless due to compatibility problems? Should the origin ever be considered when performing an HTTP referer check?

Answer 1

Here's a list of compatible browsers and known issues. Now it's up to you if you can live with these limitations:

Can I use...

Answer 2

It's a valid concern. Someone could be using an older browser that doesn't fully support it. There might also be a bug in a beta version.

Also consider adding X-Frame-Options: SAMEORIGIN to your JSON API to prevent someone from including your site into an iframe.

Also consider prepending your returned JSON responses with special characters and manually strip them off in your JSON decoder. This is how Google does it: Why does Google prepend while(1); to their JSON responses?

Also consider, for extra, extra security, to include a nonce for each request, and sign the request to verify it came from your code instead of a phishing site. This is similar to how OAuth1.0 works. An alternative, is to generate a token for each session, which automatically expires, and to refresh the token when needed. This is how OAuth2.0 works. This allows invalidating access on demand, for example, if you find a bug, so old clients must upgrade.