クロスドメイン読み込みについての記事

http://d.hatena.ne.jp/dufresne/20060802#1154514674

ドメインとデータをやりとりしたい場合はJSONPが一般的かなという感じがします。FireFox限定で構わなければgreasemonkeyを使うという手もありますし、Flashならcrossdomain.xmlで対処するのが通例かと思います。

JSONPが一般的、ってとこにちょっとだけびっくり^^;
#最近はやってるの?

ですが、JSONPのようにクライアント側のスクリプトで対処する場合にはセキュリティ上の不安もありますし、ブラウザがバージョンアップしてJavaScriptの実行に関するセキュリティを強くした場合に動作しなくなるという心配もあります。

こう指摘されたとき、JSONPがブラウザのバージョンアップで動かなくなるパターンって、どんなときだろうと考えてしまう。そもそも他サイトからのJavaScript読み込み自体が駄目になった場合、現在使われているかなりのWebアプリに影響があるのではないか。もし動作しなくなることがあるとしたら、それはDOMの操作によるスクリプトの動的読み込みのテクニックの部分かもしれないけど、そこはそんなに根本的な問題でもない気がする。

セキュリティ上の不安の指摘については、確かに納得するところはある。けれども、多少内容は明確にした上で論じてみたい。名前との類似性だけでいつの間にか「クロスサイトスクリプティング」にされちゃったりするのはちょっと嫌だし。

JSONP(およびその他の動的スクリプトロードによるJSONデータ通信)では、データ通信をスクリプト読み込みによって行っている都合上、任意のJavaScriptコードをリモートサイトが実行できるようになっている。これは最悪の場合、故意にしろ過失にしろ、そのリモートサイトを利用しているすべてのサイトが踏み台とされる可能性があるということでもある。

ただ、これは実は、Google AdSenseGoogle Analytics、あるいはみんながブログに気軽に貼り付けてるdel.icio.usバッジやその他一部のブログパーツにについても、リモートサイトに任意のコード実行を許している訳であり、結局そういうリスクがあるわけだ。実際的には、ある程度信頼できるサービスプロバイダによって提供されており、利用者がそのプロバイダを信頼しているのであればそれほど問題になるケースは少ないとも思う*1

そう考えると、実はJSONPの最大の弱点は、あらかじめ呼び出す相手を信用していなければならないことかなと思う。JSONPサービスをアプリに組み込むときは、サイトをRSSリーダー登録するように気軽にやるわけにはいかない。RSSならリモートサイトが不正なデータを送ってきても妥当性検査で撥ねてくれることを期待できるが、JSONPではリモート側が不正なものを送ってきたりしたらそのまま自動的にやられてしまう。必然的にJSONPは社会的に信頼できるエンティティ(少なくとも実名個人や企業レベル)から提供されるサービスに限定されがちになる。


次に、クロスドメインプロキシパターンを使う話について。

ここで紹介されているプロクシを用いる方法は下記のようなメリットがあるかと思います。
1. プロクシがセキュリティ上のクッションの役割を果たす
2. コンテンツの変換やキャッシュを行うことができる
3. 認証処理を自動化させることができる

特に今後重要ではないかと考えているのは2.と3.のポイントです。セキュリティ上の事情や商的な理由などで認証のかかった複数のWebサービスからデータを取得してマッシュアップするということがこれからは行われるようになるだろうと思います。その際にまず課題になるのは認証の制御です。さらに、サービス提供元のアクセス権限よりもさらに細かいレベルでコンテンツの部分的な閲覧の可否を制御したいということも出てくるでしょう。そうした場合には2.の特性がとても役に立ちます。

認証が重要だという部分については確かに同意。ただ、プロキシサーバのアプローチが万能かというと、多少引っかかる。

プロキシを介する場合は、プロキシサーバがサービス提供元に対してユーザの資格証明(簡単にはパスワード)を代理として利用する。そのため、その資格証明はセキュアに保持されることが期待されなければならず、ユーザの信頼をあらかじめ勝ち取っておく必要がある。これは通常の草の根的なマッシュアップサービスにはもしかしたら敷居が高いかもしれない。もちろんパスワードよりもセキュアなサーバ間認証のためのプロトコルはあるけれども、これはこれでまだデファクトといえるものがない。

で、JSONPでは認証のかかったWebサービスも、結局ブラウザからのリクエストであり、通常のWebリクエストと同様に扱える。マッシュアップサービス側は、ユーザがサービス提供元に対して持っている資格証明を知っておく必要はない。あくまでリクエストを投げるのはユーザであり、返ってきたデータを自分のサービスにマッシュアップさせてもらっているにすぎないからだ。

この方式には先ほどとは違うポイントで考えておくべきセキュリティがある。それは以前まとめてみたので興味のある人は御覧ください(長文だけど)。

*1:もちろんそのリスクを知らないで(知らされないで)みんなが使っているというのであれば問題だと思う