#jsonengine のHTMLエスケープとデフォルトセキュリティを考える
ayu_standaloneさんから、jsonengineについてご要望をいただきました。まずはHTMLエスケープ問題から！
HTMLエスケープについて
XSS対策はサーバ側で対処された方がよろしいではないでしょうか。 * サーバ側は生データのままで、js 側で html タグなどをエスケープする場合、もし js 側を改変された場合は対処方法が無く、とても危険な状態だと思います。
これ、ちょうどいまjsonengine開発者MLでも議論しているトピックです。Jxckさんからも同様の指摘をいただきまして、実装しようかと思ってましたが、一方でこんな意見もありました。
私：
昨日@aodagさん@najeiraさんと飲む機会が会って、jsonengineでJSクライアントのためにHTMLエスケープをサポートすべきか な？って聞いてみたら、お二人とも「jQueryのtext()でエスケープするから必要ないのでは〜」ってお答えでした。なので、サンプルクライアン トでtext()を使うやり方を載せておけば、初心者の方でもそれをまねして書くかな〜と思います。どうでしょう。
加えて、
- js以外のクライアント（Flash, iPhone/Androidアプリ）ではエスケープはあまり必要でない
- jsonengineの場合、View機能はすべてクライアント側で実装するので、エスケープもクライアントの責務としたい
- jQueryのtext()でエスケープするよう推奨するチュートリアルを載せる。jsonengine側でエスケープしていても、結局html()をどう使うかはjsプログラマーの責務となる
って要素もあります。
それと「js側が改変されるケース」とは、どのような状況でしょうか？（私あまりjs詳しくなくて済みません！）。appengine上にデプロイされたjsの改変は難しいと思いますし、他のサーバー上に改変されたjsが置かれてそれをユーザーが踏んでしまうケースはjsonengineでなくても発生しうるかなと。。
デフォルトセキュリティについて
最低でも Google アカウントでログインしたユーザのみ put や get が実行可能にすべきではないでしょうか。 * API に準拠していれば、どのような docType でも保存することができます。それゆえ、サーバ側で docType すべてをあらかじめ把握することはできないので、アクセスレベル設定では完全に制御できないと思います。 * datastore は無限に無料ではないので、やはり無制限にあらゆるアクセスが可能な状況というのは回避すべきだと思います。 * jsonengine を使用したサービスに登録したユーザのみアクセスできる、というのが最も理想的だと思います。
これ、私も相当悩みました。現在jsonengineはdocType単位でセキュリティ保護する仕組みがあり、内部的にはフラグを1つ変更するだけで「すべてのdocTypeのデフォルトセキュリティをprotectedにする」という設定にできます。明示的に指定したdocTypeのみpublicなアクセスを許可できます。
ただ、それをすると「すべての利用者が必ず管理画面上でdocType設定をしなければ動かない」ことになり、jsonengineを使い始めるまでの敷居がちょっとだけ高くなります。なので、現段階ではデフォルトセキュリティをpublicのままにしてあります。
とはいえ、もしjsonengineが普及するとこれはセキュリティホールになるので、う〜む、やっぱりもうちょっとしたらデフォルトはprotectedにしようかなぁ〜と様子を見ているところですねw
追記：登録ユーザーへの許可
もうひとつセキュリティ機能で追加が必要と思っているのが、「特定docType上（例えばRegisteredUserとか）に登録されたユーザーIDのみ読み書き可能」というセキュリティレベルです。これほしいですよね。
