Domain hijacking doesn't seem like an issue here, given HTTPS; if someone can MITM that they can do the same to my own site.
However, just because I trust a service to process payments or do any other specific business-critical task doesn't mean I trust that service to run arbitrary Javascript code in the context of my site. Customers may have significantly more sensitive data than just payment information, and third-party Javascript represents a major issue. I need the ability to confidently say to customers that no third-party service has access to their private data.
Given this new approach, I'd have to sandbox payment code off on a separate domain that has no access to other user data.
> However, just because I trust a service to process payments or do any other specific business-critical task doesn't mean I trust that service to run arbitrary Javascript code in the context of my site.
You...include their Javascript on your site to even be able to make the JSONP calls in the first place. Their "arbitrary Javascript" is on your domain already.
You certainly could audit it, locally mirror it, and then do that every time they publish an update, but are you actually going to do that?
Even without auditing it or with just a cursory audit, mirroring third-party code makes a difference. If you copy the code then you have a complete history of code changes in your own source control, which should make shenanigans unlikely since it's easily proven. That's quite a bit different than using a live third-party URL, since the third party (or an attacker) could selectively replace it for some targets and you'd never know.
So yes, it's a good idea to always check any third-party code you use into your own source control system. I would hope everyone does that.
> You certainly could audit it, locally mirror it, and then do that every time they publish an update, but are you actually going to do that?
Yes, absolutely. For any third-party Javascript, I'd either mirror it locally and review it for safety, or sandbox it on a separate untrusted domain that has no access to customer data.
I think the separate domain is a great solution in that case, but my point is that if you're worried about the use of JSONP as the transport being the insecure link, you're too late.
However, just because I trust a service to process payments or do any other specific business-critical task doesn't mean I trust that service to run arbitrary Javascript code in the context of my site. Customers may have significantly more sensitive data than just payment information, and third-party Javascript represents a major issue. I need the ability to confidently say to customers that no third-party service has access to their private data.
Given this new approach, I'd have to sandbox payment code off on a separate domain that has no access to other user data.