JSONP

JSONP, or JSON-P (JSON with Padding), is a JavaScript technique for requesting data via the <script> HTML element.^[1] It was proposed by Bob Ippolito in 2005.^[2] JSONP enables sharing of data bypassing same-origin policy, which disallows running JavaScript code to read media DOM elements or XMLHttpRequest data fetched from outside the page's originating site. The originating site is indicated by a combination of URI scheme, hostname, and port number.

JSONP requests are vulnerable to the data source replying with malicious code, which is why it has been enhanced by CORS (cross-origin resource sharing, available since 2009^[3]) in modern applications.

The HTML <script> element is generally allowed to execute JavaScript code retrieved from foreign origins. Before the adoption of CORS, services replying with pure JSON data were not able to share data from foreign origins.

For example, a CORS request to a foreign service http://server.example.com/Users/1234 may return a JSON response. However, an attempt to use the data across domains without CORS results in a JavaScript error.

When http://server.example.com/Users/1234 is passed into the src attribute of a <script> tag, the browser will download the file, evaluate its contents, misinterpret the raw JSON data as a block, and throw a syntax error. Even if the raw JSON data were interpreted as a JavaScript object literal, object literals are inaccessible without a variable assignment.

JSONP solves this by the client and server agreeing on a URL encoded query argument, conventionally jsonp or callback, which the client will use to define text that the server will prepend to its response, and wrap the JSON payload in parenthesis resulting in a JavaScript document. When the encoded URL is passed into the src attribute of the <script> element, the client sends the JSONP request and the server response JavaScript document is loaded into the browser. Typically, this is used to call a function defined in the JavaScript environment and manipulate the JSON data in the response.

An example JSONP request to http://server.example.com/Users/1234

<script type="application/javascript"
        src="http://server.example.com/Users/1234?jsonp=parseResponse">
</script>

In this example, the client defined parseResponse as the prepend text. The server response would be:

parseResponse({"Name": "Foo", "Id": 1234, "Rank": 7});

Here, parseResponse() is the "P" of JSONP—the "padding" around the pure JSON.^[4]

JSONP makes sense only when used with a script element. For each new JSONP request, the browser must add a new <script> element, or reuse an existing one. The former option—adding a new script element—is done via dynamic DOM manipulation, and is known as script element injection. The <script> element is injected into the HTML DOM, with the URL of the desired JSONP endpoint set as the src attribute. This dynamic script element injection is usually done by a JavaScript helper library. jQuery and other frameworks have JSONP helper functions; there are also standalone options.

An example of using jQuery to dynamically inject script element for a JSONP call looks like this:

$.getScript("http://server.example.com/Users/192.168.73.96?callback=parseResponse");

After the element is injected, the browser evaluates the element, and performs an HTTP GET on the src URL, retrieving the content. Then the browser evaluates the return payload as JavaScript. This is typically a function invocation. In that way, the use of JSONP can allow browser pages to work around the same-origin policy via script element injection.^[5]

The script runs within the scope of the including page and, as such, is still subject to cross-domain restrictions relative to the domain of the including page. This means that a web page cannot, for example, load a library hosted on another site via JSONP and then make XMLHttpRequest requests to that site (unless cross-origin resource sharing (CORS) is supported), although one could use such a library to make XMLHttpRequests to one's own site.

Including script elements from remote servers allows the remote servers to inject any content into a website. If the remote servers have vulnerabilities that allow JavaScript injection, the page served from the original server is exposed to an increased risk. If an attacker can inject any JavaScript into the original web page, then that code can retrieve additional JavaScript from any domain, bypassing the same-origin policy.^[6] The Content Security Policy HTTP Header lets web sites tell web browsers which domain scripts may be included from.

An effort was undertaken around 2011 to define a safer strict subset definition for JSONP^[1] that browsers would be able to enforce on script requests with a specific MIME type such as "application/json-p". If the response did not parse as strict JSONP, the browser could throw an error or just ignore the entire response. However, this approach was abandoned in favor of CORS, and the correct MIME type for JSONP remains application/javascript.^[7]

JSONP carried the same problems as resolving JSON with eval(): both interpret the JSON text as JavaScript, which meant differences in handling U+2028 (Line Separator) and U+2029 (Paragraph Separator) from JSON proper. This made some JSON strings non-legal in JSONP; servers serving JSONP had to escape these characters prior to transmission.^[8] This issue has now been rectified in ES2019.^[9]

Unsanitized callback names may be used to pass malicious data to clients, bypassing the restrictions associated with application/json content type, as demonstrated in reflected file download (RFD) attack from 2014.^[10]

Insecure JSONP endpoints can be also injected with malicious data.^[11]

Naive deployments of JSONP are subject to cross-site request forgery (CSRF or XSRF) attacks.^[12] Because the HTML <script> element does not respect the same-origin policy in web browser implementations, a malicious page can request and obtain JSON data belonging to another site. This will allow the JSON-encoded data to be evaluated in the context of the malicious page, possibly divulging passwords or other sensitive data if the user is currently logged into the other site.

Rosetta Flash is an exploitation technique that allows an attacker to exploit servers with a vulnerable JSONP endpoint by causing Adobe Flash Player to believe that an attacker-specified Flash applet originated on the vulnerable server. Flash Player implements same-origin policy allowing one to make requests (with cookies) and receive responses from the hosting site. The applet can then send the retrieved data back to the attacker. This is a cross-origin exploit with an impact similar to embedding an arbitrary Flash applet in the vulnerable domain. The exploit uses an ActionScript payload compiled to an SWF file composed entirely of alphanumeric characters by crafting a zlib stream with a particular header and DEFLATE blocks with ad-hoc Huffman coding. The resulting alphanumeric-only SWF file is then used as the callback parameter of a JSONP call. High-profile sites such as Google, YouTube, Twitter, Yahoo!, Yandex, LinkedIn, eBay, GitHub, Instagram, and Tumblr were all vulnerable until July 2014.^[13] This vulnerability was initially discovered by Erling and Alok Menghrajani, with a public presentation at a security conference. The exploitation of the vulnerability was subsequently improved by Gábor Molnár. Google security engineer Michele Spagnuolo coined the term^[14] and has CVE-2014-4671^[15] and CVE-2014-5333.^[16] Adobe Flash Player release version 14.0.0.145, released on 8 July 2014, introduced stronger validation of Flash files,^[17] and in version 14.0.0.176, released on 12 August 2014, finalized the fix,^[18] preventing this exploit from working.

Prior to Adobe's fix, websites could protect themselves by prepending an empty JavaScript comment (/**/) or even just a newline as the first bytes of the JSONP response.

In July 2005, George Jempty suggested an optional variable assignment be prepended to JSON.^[19][20] The original proposal for JSONP, where the padding is a callback function, appears to have been made by Bob Ippolito in December 2005^[21] and is now used by many Web 2.0 applications such as Dojo Toolkit and Google Web Toolkit.

• Cross-origin resource sharing (CORS)
• Cross-document messaging

• server side filter wraps any response into a jsonp callback – done with jsonp-java source code
• Potential security issues related to JSON
• JSONP data source for remote domains