Is there any security issues in using JSONP.
JSONP is just a script include that allows you to use a callback. You should however be aware of Cross-site request forgery (CSRF).
As long as you control the script and the server, JSONP isn't anymore insecure than a script include. Unless you have a JSONP-service that returns sensitive data to logged in users. If the JSONP-service doesn't check the referrer, another malicious site could send a request to the service (hoping that the user is logged in on your site), and retreive the data.
Imagine this senario: - A user logs into his internet banking account. Storing a session cookie in the users browser. This site has a jsonp service with sensitive info about the user and his accounts. - Other sites won't know that the user is logged in, but they could do a wild guess and try to access the jsonp service. Since the user has a session cookie, the browser will get a response, and there's nothing stopping the site from doing an ajax post to save the sensitive data on their server.
Yes. As in yes, there are security issues.
Here is a (more or less randomly chosen) blog post that expresses some concerns.
Here is Wikipedia's paragraph on the security issues with JSON.
Basically, it's extra important not to pass the code to eval()
blindly, as you don't know what the remote site sent you. There are also risks with the code from the remote site communicating with your current site, pretending to be you.
Yes, you need to be careful, but when used properly with trusted services it's relatively safe.
Here's a summary of the security issues with JSONP, as I understand it:
From the consumer's perspective:
- You must trust the provider to not return malicious JavaScript instead of the expected JSON wrapped in the JSONP callback you specify.
- The same is also true of any third party JavaScript embedded add-ons, such as Google Analytics.
- It's only similar to XSS attacks in that it allows a 3rd party to execute arbitrary JavaScript in your application, however, you must first choose to trust that 3rd party by making the request in the first place.
From the provider's perspective:
- You must not assume that even though the clients' cookie(s) are present in the request that the consumer is a webpage under your control. Check the Referer header against a whitelist of authorized URLs, and/or don't rely on cookie-based authentication.
- Analogous to a CSRF / confused deputy attack.