http://directwebremoting.org/blog/joe/2007/03/06/json_is_not...
Doing a `while(1);` would be much more robust.
If you only return data to XHRs then you're protected by same origin policy and all <script> tags will get no data.
-EDIT-
When I first read "a better option is to require custom XMLHttpRequest headers" I thought this is what they were talking about. After a second look they probly mean setting a custom header yourself using the XHR object. This would work too but now I'm wondering if there's some way around my solution. Because why would they advocate a custom header if checking the X-Request-With header alone is enough?
- EDIT -
Was just in the shower and remembered why they probly don't advise to just check the X-Requested-With header. There are ways for an attacker to get around the XHR same origin policy with dns pinning/rebinding attacks. If you required a custom header with a session cookie which the attacker didn't have access to this would mitigate that kind of attack. EDIT: Nevermind, as long as you're checking the Host header a dns rebinding attack wouldn't matter.
Obviously this is only true for read operations: anything that updates state would still be vulnerable to CSRF (since you don't need to be able to read the result to make the request).
So since you can't force an Origin header to be on all of your legit API requests, you won't be able to differentiate them (using the Origin header) from an attacker with a <script> tag.
Edit: I was confusing X-Requested-With and Origin. My apologies.