Ajaxが流行していますが、まだ、僕個人では実装レベルまでライブラリの蓄積が追いついていません。
各種ライブラリがWebフレームワークレベルでそろったら（そろえたら）使いたいなと思っていますが、なかなかそこまで手が出てないのが現状です。
とはいえ、社内でもDojoや、MochiKitなどのフレームワークがはやりつつあるので、そろそろつかいたいかなーと思いセキュリティを含めたリスクを調査しています。
とはいえ、まだまだ勉強中の身であるので、突っ込みいただけると助かります。
(1) クロスサイトスクリプティングに注意する
基本的な対策は、サーバサイドのときと同じく、描画を行うタイミングでエスケープ処理を行うことになります。
だだし、HTTPヘッダではなくBodyにエスケープしてない文字列をおいた場合にはAjaxではなく直接アクセスすると、XSSになる場合があるので注意が必要です。
エスケープ処理を行うのは、通常HTMLのレンダリングする場所ですが、上記のようなJavaScript経由でないアクセスも考慮に入れる必要があります。
HTTP上にエスケープしていない文字で通信する場合には、Ajax経由でないアクセスのこともHTTPのBODY部分ではなく「HTTPヘッダに入力するタイプのJSON」などを使うべきです。
Ajaxだけしかアクセスしねぇやーとか思ってると、罠のURLを踏んだユーザがアクセスしてしまう場合があります。
また、JavaScriptによるWYSIWYGで生のHTMLを操作できるライブラリなどを作成したり利用したりする場合には、それ自体にXSSが存在しないかどうか注意深く調査する必要があります。
もちろんサーバサイド側で全部エスケープ処理を付すのが一番楽だと思います。
(2) SEO対策に問題が生じていないかを注意する
本来クロールされたい項目がJavaScriptでしか抜き出せない状況になっている場合には、クローラーはクロールしてくれません。
SEOが必要なサイトでは、静的なページを用意するなどの対策が必要です。
(3) 不要な情報を公開していないか
たとえば、登録フォームにバリデータとして登録されているメールアドレスやIDかをチェックして「このIDは登録できます。」などと表示するといった処理を行うときには注意が必要です。
なぜならば、そのチェック処理を行うサーバサイドのインターフェースに、スクリプトなどで直接大量のIDを流し込むことにより容易にそのIDが使われているかチェックすることができます。
とはいえ、既存の登録フォームでも、スクリプトを流せばチェックできるものもありますので(CAPTCHAである程度は防衛できそうです。）リスクとしてはクリティカルではないと思いますが、技術者としてはベストプラクティクスを用意しておきたいものです。
(4) 通信量とアクセス頻度に注意する
わりと当たり前なのですが、onKeyPress系統をトリガーにするJavascirptにおいては、HTTP通信が発生するような処理は避けるべきです。
なぜなら、キー入力があった数だけ、HTTPリクエストが発生するからです。
すでにイベントが発生していたら処理しないなどの処理をはさむことで回避は可能ですが、何も考えずにやると痛い目を見ます。
(5) そもそも、お前、Ajaxいいたいだけじゃないかと
独りよがりのUIにはなりたくないものです。
上の4つに対してもそうですが、如何にかっこいいUIにするかを考えるよりは如何に使いやすいUIにするか、使ってて気持ちいUIにするかが重要です。
社内には、AjaxもFlashも使う人がいるので今度教えてもらいながら勉強します。
前回、見事に、逆SBOをしてしまった私ですが、今回もタイトルで逆SBOになりそうです。ほげほげ