title: Safe implementation of script tag hack to do XSS?
body: <p>Like a lot of developers, I want to make JavaScript served up by Server "A" talk to a web service on Server "B" but am stymied by the current incarnation of <a href="http://en.wikipedia.org/wiki/Same_origin_policy" rel="nofollow noreferrer">same origin policy</a>. The most secure means of overcoming this (that I can find) is a server script that sits on Server "A" and acts as a proxy between it and "B". But if I want to deploy this JavaScript in a variety of customer environments (RoR, PHP, Python, .NET, etc. etc.) and can't write proxy scripts for all of them, what do I do?</p>
  
  <p>Use JSONP, <a href="http://remysharp.com/2007/10/08/what-is-jsonp/" rel="nofollow noreferrer">some people say</a>. Well, Doug Crockford pointed out <a href="http://javascript.crockford.com/script.html" rel="nofollow noreferrer">on his website</a> and <a href="http://thechangelog.com/post/676820023/episode-0-2-6-douglas-crockford-on-json-and-javascript-f" rel="nofollow noreferrer">in interviews</a> that the script tag hack (used by JSONP) is an unsafe way to get around the same origin policy. There's no way for the script being served by "A" to verify that "B" is who they say they are and that the data it returns isn't malicious or will capture sensitive user data on that page (e.g. credit card numbers) and transmit it to dastardly people. That seems like a reasonable concern, but what if I just use the script tag hack by itself and communicate strictly in JSON? Is that safe? If not, why not? Would it be any more safe with HTTPS? Example scenarios would be appreciated.</p>
  
  <p><strong>Addendum:</strong> Support for IE6 is required. Third-party browser extensions are not an option. Let's stick with addressing the merits and risks of the script tag hack, please.</p>