简介
JSONP扩展名.jsonp互联网媒体类型application/json-p格式类型数据交换扩展自JSON与JavaScript标准RFC 7159, RFC 4329网站www.json-p.org(失效链接，参见网页存档)JSONP（JSON with Padding）是资料格式JSON的一种“使用模式”，可以让网页从别的网域获取资料。另一个解决这个问题的新方法是跨来源资源共享。由于同源策略，一般来说位于server1.example.com的网页无法与server2.example.com的服务器沟通，而HTML的
服务器会在传给浏览器前将JSON数据填充到回调函数（parseResponse）中。浏览器得到的回应已不是单纯的资料叙述而是一个脚本，这样浏览器就可以调用该函数进行处理。在本例中，浏览器得到的是：
parseResponse({"Name": "小明", "Id": 1823, "Rank": 7});
填充
虽然这个填充（前辍）“通常”是浏览器执行背景中定义的某个回调函数，它也可以是变量赋值、if叙述或者是其他JavaScript叙述。JSONP要求（也就是使用JSONP模式的请求）的回应不是JSON也不被当作JSON解析——回传内容可以是任意的表达式，甚至不需要有任何的JSON，不过惯例上填充部分还是会触发函数调用的一小段JavaScript片段，而这个函数调用是作用在JSON格式的资料上的。
另一种说法—典型的JSONP就是把既有的JSON API用函数调用包起来以达到跨域访问的解法。
Script元素“注入”
为了要启动一个JSONP调用（或者说，使用这个模式），你需要一个script元素。因此，浏览器必须为每一个JSONP要求加（或是重用）一个新的、有所需src值的元素到HTML DOM里—或者说是“注入”这个元素。浏览器执行该元素，抓取src里的URL，并执行回传的JavaScript。
也因为这样，JSONP被称作是一种“让用户利用script元素注入的方式绕开同源策略”的方法。
安全问题
使用远程网站的script标签会让远程网站得以注入任何的内容至网站里。如果远程的网站有JavaScript注入漏洞，原来的网站也会受到影响。
现在有一个正在进行项目在定义所谓的JSON-P严格安全子集，使浏览器可以对MIME类别是“application/json-p”请求做强制处理。如果回应不能被解析为严格的JSON-P，浏览器可以丢出一个错误或忽略整个回应。
跨站请求伪造
粗略的JSONP部署很容易受到跨站请求伪造（CSRF/XSRF）的攻击。因为HTML 标签在浏览器里不遵守同源策略，恶意网页可以要求并获取属于其他网站的JSON资料。当用户正登录那个其他网站时，上述状况使得该恶意网站得以在恶意网站的环境下操作该JSON资料，可能泄漏用户的密码或是其他敏感资料。
只有在该JSON资料含有不该泄漏给第三方的隐密资料，且服务器仅靠浏览器的同源策略阻挡不正常要求的时候这才会是问题。若服务器自己决定要求的专有性，并只在要求正常的情况下输出资料则没有问题。只靠Cookie并不够决定要求是合法的，这很容易受到跨站请求伪造攻击。
历史
2005年夏天，乔治·詹姆提（George Jempty）建议在JSON前面选择性的加上变量赋值。鲍勃·伊波利托（Bob Ippolito）于2005年12月提出了JSONP最原始的提案，其中填充部分已经是回调函数，而现在已有很多Web 2.0应用程序使用这份提案，像是Dojo Toolkit应用程序、Google Web Toolkit应用程序与Web服务。