Ok, fair enough, that addresses my last paragraph.
But I still don't see what problem this sanitization solves. For a JSONP source to be useful you need to specify your own callback, not rely on one provided by a user input. Shouldn't you strip the callback and add your own?
Furthermore, even if there was a reason to keep the user specified callbacks, shouldn't the application that's consuming the URLs do the sanitization, not the JSONP provider?
It's your responsibility to secure your app, not the 3rd party JSONP providers.
Good points. I was imagining a scenario in which users/other-app-providers would be able to define their own Javascript functions, Google Caja http://code.google.com/p/google-caja/ style... in which case, the app should simply only need to whitelist adding trusted hosts/base urls to <script src="" />...
Also, see Drew's comment below where he was able to find an XSS exploit in FriendFeed due to them accepting '<' and '>' in the callback value... a reflection of how most security exploits come from combining different vulnerabilities.
But I still don't see what problem this sanitization solves. For a JSONP source to be useful you need to specify your own callback, not rely on one provided by a user input. Shouldn't you strip the callback and add your own?
Furthermore, even if there was a reason to keep the user specified callbacks, shouldn't the application that's consuming the URLs do the sanitization, not the JSONP provider?
It's your responsibility to secure your app, not the 3rd party JSONP providers.