jsonp安全性防范，分为以下几点：
1、防止callback参数意外截断js代码，特殊字符单引号双引号，换行符均存在风险
2、防止callback参数恶意添加标签（如script），造成XSS漏洞 3、防止跨域请求滥用，阻止非法站点恶意调用针对第三点，我们可以通过来源refer白名单匹配，以及cookieToken机制来限制
而前两点，传统的做法分为以下几种： 1、纯手工过滤特殊字符，引号尖括号等，一旦发现潜在恶意字符则服务端拒绝，返回错误。此种方式较为严格，但是随之而来的问题是失败率会有所提升，尤其对于对外开发者。而且JS中恶意字符的变形十分多，此方式需要枚举所有非法字符，可能存在疏漏。我们不应该将潜在的恶意字符都一概屏蔽，因为确实有些需求需要传入并存储这些字符。 2、对于callback参数作严整的格式检查，或强制约定指定格式。基本可以彻底解决安全问题，但同样是对调用端不是完全透明，使用者需要额外去知晓相关限制和约定，可能会造成不必要的沟通成本。 3、返回包体添加header头部，强制指定MIME类型，避免按HTML方式解析，防止XSS漏洞。这似乎是个很完美的解决方案。但是十分诡异的是，在某些版本的火狐浏览器下，直接访问MIME类型为JAVASCRIPT的请求时，浏览器仍然会按照HTML解析。或许是该浏览器设计的缺陷，但它忽略了我们设置的header。无法保证所有浏览器严格按照MIME类型解析。我们的关注点一直在于如何限制用户输入，但是请从另外一个层面去考虑该问题，或许就会豁然开朗。
我们先了解一下JS本身的特性。
JSONP的本质是构造全局回调函数，之后加载script标签触发回调函数。 通常我们使用函数可以这么写function test(){}test(); 而在全局的函数也就默认是window的成员。也可以显示书写为
window.test = function(){};window.test(); 而JS中对象的成员是可以使用字符串索引的方式访问的，故进一步改造为
window['test']=function(){};window['test'](); 现在有注意到么，如此一来我们已经把函数名已经完全限制在了字符串上下文，理论上只要做好了防注入工作，callback参数是不可能跳出字符串上下文意外执行代码的。以PHP为例，单字符串防止注入甚至可以直接使用json_encode该字符串实现。
window['alert("123");abc'](); 上面的callback参数虽然有注入的风险，可以由于callback参数严格限制在字符串内部，仅会作为文本，不会意外执行
但仍然存在xss漏洞问题,看下面例子
window['']();
我们虽然已经保证了<script>严格限制在引号内部，不会造成js注入，但是直接在浏览器中输入该jsonp请求仍会按照HTML解析，产生XSS漏洞，即便设置了header也很难防范。
在进一步，我们只需要保证浏览器内不会明文出现<>标签，那么问题便可彻底解决。
基本思路是在服务端做一次urlencode。而在output输出decodeURIComponent(‘#####’)来规避显示尖括号。Urlencode过的字符串，只可能包含字母数字%，也顺便解决了注入的问题最终附上一段简短的代码。根本解决jsonp的安全问题
请求1：http://www.test.com/a.php?callback=alert(123);abc
响应1：window[decodeURIComponent('alert(123)%3Babc')]({ret:0,msg:'OK'});
请求2：http://www.test.com/a.php?callback=<script>alert(123);</script>
响应2：window[decodeURIComponent('%3Cscript%3Ealert(123)%3B%3C%2Fscript%3E')]({ret:0,msg:'OK'});
上述几个例子都可以证明jsonp安全漏洞已被彻底规避，即便存在尝试注入的恶意参数，仍能最大限度保证程序完全正常工作触发回调。