Ajaxを利用したシステムを構築する際に配慮すべき事項はいくつかあるが（表1），ここではセキュリティ上の懸念について言及しておきたい。

表1●Ajaxのシステム構築で留意すべきポイント
[画像のクリックで拡大表示]
表1●Ajaxのシステム構築で留意すべきポイント

　まず，XHRでは，機密データを送る特定のリクエスト/レスポンスだけをSSL（Secure Sockets Layer）で暗号化できない。「同じ画面から送られるXHRは，全部暗号化するか，全部平文にするかのどちらかになる」（NTTデータ 木村氏）。全部暗号化すると処理負荷が重くなるので，ログイン画面はSSLで暗号化しているのに，業務画面は暗号化せずにXHRで送受信しているシステムが散見される。少なくとも，セッション情報などを盗まれない設計を検討すべきだ。暗号強度は低いが「aSSL」などのJavaScript暗号ライブラリの利用を考えたい。

　次は，ソースコードが読まれるリスクである。クライアントにダウンロードしたJavaScriptのコードは丸見えなので，そのコードを分析されると，サーバー側のアプリケーションを推測されやすくなる。人間に理解しにくいコードに変換する「難読化ツール」（変数名を数字列に変えるなどの方法）を使用する開発者もいるが，難読化したコードを逆に読みやすくする「可読化ツール」もあり，気休めにしかならない。

　また，コードはクライアント側で参照できるだけでなく書き換えることも可能である。それゆえ，クライアント側のJavaScriptで入力値をチェックしていても，悪意のある利用者を想定してサーバー側でデータの正当性をチェックしなければならない。

　Ajax用のサーバー側サービスを別のWebシステムから呼び出して利用する“マッシュアップ”を許可する場合，JavaScriptのクロスドメイン実行の可否を慎重に設計したい。本来Webブラウザは，あるドメインで提供するJavaScriptを別ドメインのWebシステム上では実行できないように制限している。ところがJSONなど一部のライブラリを使うと，この制限を突破してクロスドメイン環境でJavaScriptを実行できるようになる。

　これは便利な面もある一方で，Ajaxのサービスにクロスサイト・スクリプティングなどの脆弱性があると，マッシュアップにより連携しているシステムまでも脅威にさらされる。「Ajaxのサービス経由で攻撃コードを含むコンテンツをクライアントに送り込めれば，Webブラウザの表示を乗っ取れてしまう」（日本IBM 東京基礎研究所 サービス指向コンピューティング 課長 浦本直彦氏）。利用者に機密情報を入力させ，クラッカーのサーバーに送信させる“フィッシング”が可能になるというわけだ。Ajax関連のセキュリティを研究する同研究所の吉濱佐知子氏（主任研究員）は，「信頼できるかどうかをドメインでしか判定しないWebブラウザのセキュリティ・モデルは現状にそぐわなくなってきた。マッシュアップを想定した新しい解決策が必要だ」と指摘する。