Skip to content

Instantly share code, notes, and snippets.

Created Aug 15, 2013
What would you like to do?
Why JSONP is a terrible idea and I will never use it again

Moral Concerns

JSONP is not actually JSON with padding, it's Javascript code that's executed. JSON is not a real subset of Javascript and the way it is not is important to us: via UTFGrid, we are all UTF-8 masters.

JSONP is not safe: it's Javascript that's executed. It's trivial to XSS with JSONP, because JSONP is XSS. Just have a call like mapbox.load('foo.tilejson', …) and if foo.tilejson gets replaced with destroyYoursite(), it gets run. Compare to JSON.parse, which is, on purpose, not eval.

Practical Concerns

JSONP is questionable in terms of performance. To be fast, you want to have the same callback all the time so that you can cache the response. But this leads to a page like


In which the grid function is called by several relatively-anonymous script tags in quick succession. The events browsers give us for script loading suck: the load event isn't the 'evaled and executed' event, it's just the load event. That sucks.

The less performant way to do things is with dynamic callbacks, like foo.php?callback=foobar123213. So every response needs a new request and your cache sucks.


The future is CORS but it isn't the present: it isn't supported on IE<10. So, we're jfdi'ing it: which means XDomainRequest. Which sucks.

IE sucks, but you choose your kind of suck: the restrictions of XDomainRequest - only the GET HTTP verb, no headers, etc - shouldn't matter to us.

One thing: unlike JSONP, where HTTPS throws a warning but can work, XDomainRequest totally falls flat on HTTP->HTTPS or vice-versa.

What the World Really Needs is an Ajax Library Written By Me



This comment has been minimized.

Copy link
Owner Author

@tmcw tmcw commented Jul 8, 2014


This comment has been minimized.

Copy link

@47ronin 47ronin commented Nov 28, 2016

Are most AngularJS $http.jsonp() projects vulnerable, to some extent?


This comment has been minimized.

Copy link

@aligajani aligajani commented Dec 7, 2016

I think so


This comment has been minimized.

Copy link

@crazytonyi crazytonyi commented Apr 13, 2018

CORS isn't really the answer, I don't think. Because it's just a check on the remote server to see how they feel about their resource being retrieved from another site. If my intention is to use ajax to get the browser to download some crazy evil shit from a remote URL, I'm going to make sure that the remote site has Access-Control-Allow-Origin: * set.


This comment has been minimized.

Copy link

@danielpaull danielpaull commented Jul 20, 2018

So long as you don't blindly eval() the crazy evil shit then you should be just fine.


This comment has been minimized.

Copy link

@ThunderSon ThunderSon commented Jul 30, 2018

They would be vulnerable if calls to sensitive/private info is retrieved from the JSONP call, where data exfiltration could occur by luring users and using XSS to extract the data from that call to your own hosted server (JSONP can be called from anywhere unless referrer is whitelisted server side)


This comment has been minimized.

Copy link

@tomchadwin tomchadwin commented Jul 31, 2018

Any security concern with JSONP if it's on the same site/domain?


This comment has been minimized.

Copy link

@wesleyvicthor wesleyvicthor commented Aug 15, 2018

say that security breach to google which uses jsonp for gtm.


This comment has been minimized.

Copy link

@Lewiscowles1986 Lewiscowles1986 commented Feb 1, 2021

Well that Flash trick shouldn't work any more since flash is now disabled in modern browsers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment