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']();
现在有注意到么，如此一来我们已经把函数名已经完全限制在了字符串上下文，理论上只要做好了防注入工作，callback参数是不可能跳出字符串上下
文意外执行代码的。以PHP为例，单字符串防止注入甚至可以直接使用json_encode该字符串实现.
window['alert("123");abc']();
上面的callback参数虽然有注入的风险，可以由于callback参数严格限制在字符串内部，仅会作为文本，不会意外执行,但仍然存在xss漏洞问题
看下面例子
window['<script>alert(123);</script>']();
我们虽然已经保证了<script>严格限制在引号内部，不会造成js注入，但是直接在浏览器中输入该jsonp请求仍会按照HTML解析，产生XSS
漏洞，即便设置了header也很难防范。
在进一步，我们只需要保证浏览器内不会明文出现<>标签，那么问题便可彻底解决。
基本思路是在服务端做一次urlencode。而在output输出decodeURIComponent(‘#####’)来规避显示尖括号。Urlencode过的字符串，只可能包含字母
数字%，也顺便解决了注入的问题.
最终附上一段简短的代码。根本解决jsonp的安全问题
<?php header('Content-type: text/javascript'); //加上此句可以消除chrome的警告 $callback = urlencode($_GET['callback']); echo "window[decodeURIComponent('{$callback}')]({ret:0,msg:’OK’});"
请求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安全漏洞已被彻底规避，即便存在尝试注入的恶意参数，仍能最大限度保证程序完全正常工作触发回调。