Ajaxはクライアント・サイドのJavaScriptと，サーバー・サイドのWebサービスが協調して動作する。このうちJavaScript部分は利用者のWebブラウザ上で実行するので，ソースを秘匿できず変更される可能性がある。変更されることにより，不正な引数でWebサービスが呼び出されるかもしれないし，Webサービスが想定外の使われ方をされるかもしれない。
ここでは，株価を5分ごとに表示するAjaxアプリケーションで考えてみよう。用意しているWebサービスは，証券コードを引数として渡すと，その株価を結果として返すもの。そうしたWebサービスを，クライアント側のJavaScriptから5分ごとに呼び出す構成になっている。
 図6●改変されたクライアント・プログラムから利用される恐れがある Webサービスの引数に証券コードを渡して戻り値で株価を返すようなアプリケーションの場合，JavaScriptのプログラムを改変して当初予定していたのとは異なる目的で利用されることが考えられる [画像のクリックで拡大表示] |
 図7●Webアプリケーションに依存したWebサービスにすることで転用を難しくする Webサービスの引数に相当する情報を，セッション領域を使って受け渡しする。こうすることで，クライアント・プログラムの転用による想定外の呼び出しを防ぐ [画像のクリックで拡大表示] |
このような構成では，JavaScript部分の改変による影響を受けやすい。まず，呼び出し間隔は，ソースを変更することによって1秒間隔など極端に短い間隔に変更できてしまう。そのほか，全証券コードをループ処理で次々と渡して，その値動きをグラフ化するソフトを何者かによって作られる可能性もある。それはWebサービスの作成者が意図しない使われ方で，Ajaxアプリケーションの転用と言えよう。このような改変や転用により，Webサービスに対するトラフィックは増大し，想定外の負荷がかかる恐れがある（図6[拡大表示]）＊10。
以下では，こうした改変や転用に対する，Webサービス側の対策を説明する。
利用者ごとの呼び出し回数を制限する
トラフィックの増大を抑える一つの方法は，利用者ごとの呼び出し回数を制限することだ。だが前述したようにWebブラウザ上で動作するJavaScriptは改変される恐れがあるので，クライアント側で呼び出し回数を制限できない。
利用者ごとの呼び出し回数の制限は，Webサービス側に実装するしかない。Ajaxは通常のWebアプリケーションと同じく，認証機能やCookie機能，セッション機能（Webアプリケーションのフレームワークが提供する）を利用できる。最も簡単なのは，セッション機能を利用する方法である。同一セッションからの呼び出しが一定時間内に規定回数を超えると，それ以上は応答を返さないようにする。
しかし，セッションは接続し直せば新しく作成されるので，悪意ある利用者が何度もつなぎ直す操作をしたり，あえてCookieを送信しないようにしたりされると効果がない。
そこでさらなる対策として，会員制とする方法が考えられる。利用者ごとにアカウントを与え，Webサービスを利用する際に認証する。もし誰かが予想以上に高負荷のリクエストを送ってくるようであれば，そのアカウントを無効にすることで対処できるようになる。
Webアプリケーションに依存させる
インターネットに公開しているWebサービスの場合，そのWebサービスが返すデータをほかの用途に転用される危険性は常にある。Webサービスの返すデータがWebアプリケーション特有のデータで，ほかに転用してもメリットがないならまずそのような心配はいらないだろう＊11。だが証券コードから株価を返すサービスのように，汎用的に使えるデータを提供する場合には転用される可能性が高くなる。
Ajaxでは実行コードがクライアント側のJavaScriptに実装されるという構成上，解析されないようにするのは不可能であり，他用途への流用を完全に避けることはできない。ただ，完全に回避することはできないが，データを暗号化したり，アプリケーションの構成を複雑にしたりしておけば転用が難しくなる。
複雑にする方法の一つとして，WebアプリケーションとWebサービスが連動して動くような構成が考えられる。例えば証券コードをWebサービスの引数に渡すのではなく，Webアプリケーションのフォームで入力し，それをセッション領域に保存してWebサービス側で取得するという方法である（図7[拡大表示]）＊12。
こうすることで，Webアプリケーションと連動しない呼び出しは，想定外の使われ方と判断できるようになる。もしこうした構成で想定外の使われ方をされたとしても，入力フォームのフィールド名やそれに結びついたサーバー・プログラムのフォーム処理を変更すれば，想定外のプログラムによる利用を排除できる。
通常のWebサービスは“単体で動くこと”を目的に作るが，Ajaxで使うWebサービスの場合には，あえて“Webアプリケーションと連動しないと動かない”ように作る。Webアプリケーションとの依存性を高めることで，他用途への流用を防ぐのに効果がある。
開発にはライブラリやフレームワークを使う
前編と後編に分けてAjaxアプリケーションを説明した。これまでの説明から分かるように，AjaxアプリケーションはJavaScriptを使ってWebサービスを呼び出すものにすぎず，構造は簡単である。しかし構造が簡単だからといって，Ajaxアプリケーションを作るのが簡単だとは言えない。問題を複雑化させているのは，JavaScriptである。JavaScriptの挙動はWebブラウザによって異なり，その挙動の差を吸収するのが難しい。
そこで重要なのが，Ajaxアプリケーション開発を支援するためのライブラリやフレームワークの利用である。ライブラリやフレームワークは，アプリケーションの構築を容易にするだけではない。今後新しくWebブラウザが登場したときにも，ライブラリやフレームワークを使っておけば，それを差し替えるだけで動く可能性が高くなり，メンテナンス性に優れる。
率直なところ，現時点で本格的なAjaxアプリケーションを作るのは時期尚早だと思われる。というのは，これぞという決定的なAjaxライブラリがまだなく，ライブラリを使わなければWebブラウザの互換性の面で不安が残るからだ。今の時点でAjaxを採用するとすれば，動作状況のステータス表示や，リスト・ボックスで何かが選択されたときに，もう一方のリスト・ボックスに選ばれた値に応じた値を動的に表示するといった，ごく簡単なものにとどめておくのが無難であろう。
とはいえ，開発ツール・ベンダーもAjaxに力を入れ始めており，近い将来，Ajaxが主流になる下地は整ってきている。Webアプリケーションにおいて，Ajaxはユーザー・インタフェースの概念を大きく変えるのは間違いない。Ajaxライブラリや開発ツールがそろってきたら，是非とも採用を検討したい技術である。
