今回、webサービスを開発する際にサーバ側もフレームワークを使わず１から作ることに。そこで一つ考えたことが、「URLにIDのような、内部的な値を使ってしまっていいのか」ということ。
色々考えたり調べた結果をまとめたいと思います。
※あくまで一個人の意見です。何かあっても責任は負いません。これが最適解もしくは唯一解と言う気もありません。
概要
各テーブルにIDを持ったとして、そのIDをURLにしてアクセスしたり操作したり。。と言うのが良いのかどうか。
例：service.com/user/?id=1234abc
不安になりそうなポイントとしては「IDがバレることで不正な操作が可能になってしまうのでは？」というところ。
- 他人のidを指定して他人の登録情報を編集、削除する
- リクエストを他人のidで実行したかのように見せかける
その他いろいろリスクは思い付きます。
考察
まず、ここで前提とするべきなのは、「id等の情報は基本バレる」ということ。
じゃあどのようにシステムを守るのでしょう？
大事なのは操作に対する「権限」を意識することです。
概要で挙げたような攻撃は、シンプルなログイン処理を実装しただけでは防ぐことはできません。ログインした時点で、各APIやformの処理は正常な操作として通ってしまうので、一般的なstateパターンでも防ぐことができなくなってしまいます。
そのため、ログインしたユーザにその処理を行う権限があるかどうかを確認する必要があります。
ユーザ情報を編集できるのは普通その本人だけですよね。user/edit/?id=1234 というパスでユーザ情報を編集したとして、その処理を行った現在のログインユーザのidが違うのなら弾くという処理が必要になってきます。
まとめ
個人的には、「セキュリティのポイントを考え込んでいるのなら、IDを含むことは問題無し」というふうに落ち着いています。
現実世界でもそうですが、名前等の個人情報はやむなく流出します。しかし「権限・認証・認可」がうまく機能していれば問題にはならないのです。
またこの辺りの考えは例え立派なフレームワークを使っていても考慮が必要なところだと思います。果たして「権限・認証・認可」がうまく機能しているかどうか、見落としているパターンがないかは特にバックエンドエンジニアは意識しておきましょう！
