よりセキュアなアプリケーションを作るには

まず、セキュリティとは完全にするのは非常に難しいことです。よって「よりセキュアにすることで、被害を最小限に防ぐ」という努力を行う必要があります。

基本的なWEBアプリケーションのセキュリティ対策についてはIPAの「安全なウェブサイトの作り方」が参考になります。この連載ではカバーしきれないことばかりですが、OpenSocialアプリとして気をつけるべきポイントをいくつかご紹介します。

実装面

mixiアプリにかかわらずWEBアプリケーションを作る上で必ず意識しなければいけないことがあります。それは「ユーザー（クライアント）から送られてくるデータは信頼できない」ということです。

例えば、結果（スコア）を競うようなアプリを作る場合を考えてみましょう。ゲームを行いその結果をサーバーに送り結果を他のユーザーと共有するような実装を行ってしまうとデータ処理や外部通信部分が隠ぺいできないため、悪意あるユーザーはユーザースクリプト（user.js、GreaseMonkey等）やProxyを使用することでデータを簡単に改ざんすることが可能です。

では改ざんされるということは何が悪いことなのでしょうか？自分のスコアを操作できるぐらいならいいのでは？とも考えられるかもしれません。ですが、これは個人単位で使用するのか多人数が共有して使用するのかで意味合いが変わってきます。ユーザーは自分のデータや自分を取り巻く環境（状況）が自分の意志とは別に変化することを好みません。またユーザー自身の時間や金銭といったコストをそのアプリケーションに費やしている場合はさらにその思いが強くなるはずです。

JavaScriptAPIのデータの完全性について: OpenSocialアプリとして気をつけなければならない点としてはJavaScriptAPIで取得した情報を完全に信用することは危険だということです（上記で書いた改ざんの恐れがあります）。例えば使用しているユーザーのマイミク情報がシステム的に重要な要素であればJavaScriptAPI経由で取得するのではなく、RestfulAPI経由で取得するべきです。
詳細情報：mixi Developer Center「RESTful API仕様」
外部との通信やユーザー認証を行う: 外部と通信する場合、どのユーザーに紐付いた情報かを検証する必要があります。その場合は署名付きリクエストを使用すべきです。データを受け取る側は付与されている情報から署名付きリクエストが正しいものか検証しましょう。また、予想外の入力を防ぐためにバリデーション機能を実装したほうがよいでしょう。
詳細情報：mixi Developer Center「外部サーバを呼び出してみよう」

またサービスを復旧させるためにデータのバックアップを取っておきましょう。

運用面

セキュリティというと実装面ばかりに目がいきがちですが、サービスを提供する環境や日々の運用にも注意が必要です。

社内システム、サービス提供環境のウィルス汚染を防ぐ: 汚染したパソコンやUSBメモリは社内システムを内部から広域に渡って汚染する恐れがあります。
サービス提供者のウィルス感染はユーザーから見れば、「被害者」ではなく二次被害を引き起こした「加害者」という扱いをされてしまいます。
セキュリティ情報をこまめにチェックし、使用している製品の脆弱性に対応する必要がある場合はセキュリティフィックスされたバージョンにアップグレードする、製品の使用を中止するといったことを検討・実行してください。
ログの出力やデータのバックアップ: 脆弱性の報告を受けたらまず行うのは、原因となるバグを発見することでしょう。WEBサーバーやWEBアプリケーションフレームワーク等のログを出力するようにし、ある程度の期間保管するといったことを行いましょう。ログがあるかないかでは対応のスピードがかなり変わってくる場合があります。