この話題は、現状ではイントラネットで使うような、ログインして使うタイプの「複雑な Web アプリ」の開発者の悪夢なんです。うん、

Web アプリで、自分が表示可能なURLを持った一覧リストが表示されていて、そこからリンクをクリックして「自分の情報」を見る

という流れの処理で、

じゃあ、「自分の情報」を表示するURLではなくて、本来自分が表示できないはずの他人の情報のURLを推測構築し、手で直にアドレスバーに打って、表示.....できちゃう！

という問題の対策、いわゆる「直打ち対策」のことです。とはいえここでは、本当に「手でアドレスバーに入力して...」というものだけではなくて、

送られてきたHTMLの内容をチェックして、「何を送ればいいか」が理解できる状態で、しかもセッションＩＤなども正しく使うことができて、POSTメソッドによるリクエストをでっちあげることができる

という「シロートじゃないハック」ができる一番広い状態の話でいきましょう。まあ、イントラネット用Webアプリの場合は、

そんなこと言ったって、ヘンにハックして他人の情報を覗いていた不良社員はそのうちクビになる

という現実問題（苦笑）もあるわけです。また、ある程度は、

画面ごとに付与された、「管理者だけ表示可能」というような「ロールベースの画面表示特権」

をうまくセットすることで、防御できることもあります...が、

同じロールのグループに属する他人だと？

やはり問題が起きてしまいます.....あるいは Struts の TransactionToken のように「遷移が正しいか？」をチェックする仕組みもありますが、これ「遷移が正しいか」しか判らない（アドレスバーに手で入れる、という狭い意味での「直打ち」は判るけども...やろうと思えば「模倣」はできちゃいます）ので、この話の解決とは少し違うんです（変更されるはずのないＩＤの値のハッシュとかからトークン値を生成して、「このIDは選択可能なものとして送ってない」ことが検出できないとダメ）。

ブラウザをはじめとする、ユーザエージェントが送ってくるデータなどというものは、すべて捏造可能で何一つ信用できない

という Web アプリの宿命みたいなものが本質的な原因となるわけです。ですから、面倒とは思っても、イチイチの実際の他人に見られたらイヤな情報表示画面で、

ホントにこのアクセスに対して、中身を開示していいですか？？？

というチェックを確実に入れないと、本質的な解決にならないわけです。

そうは言っても、現実の開発スケジュールにそういう余裕があるかどうかは別ですし、ＱＡがそういうチェックをしっかりしてくれるかどうか、も別です。

一度ログインしちゃったら、あとは無法地帯

な Web アプリって、 意外に多いように推測されます....私はできるだけそういう事態にならないように警戒心を持って書いてますけどね....

いろいろなフレームワークで、POSTメソッドとGETメソッドを無差別に扱える、という開発上便利な前提って、実はアドレスバーに表示されてはまずいIDが出てしまう原因のひとつのように思います。GET メソッドによる アクセス URL 構築は、つけ込まれる隙が出来がちでもあるので、出来る限り避けた方が無難、なんですけどね（便利なんでついつい...って多いですね）。.

そういえば、１つの店舗に１台しかパソコンがなくて、接客で Web アプリのページを開いたままパソコンの前を離れることがあって....で、ログインされたアカウントさえも、ページ表示をするためには信用できない！という強烈なケースさえあるようです.... ふう。