URLにIDを含めるとどんなリスクがある？

[gosaaan1]

問題点

• int型の場合は値が推測できてしまい、不正アクセスにつながる。

解決案1：リクエストボディにIDを入れて送信する。

• ブラウザの履歴やログにIDが残りにくくなる。
• リクエストの意図が明確になる。
• URLのサイズ制限の制約を受けなくなる。

解決案2：UUIDなど推測困難な値を用いる。

• 順序性を持ったUUIDv1（タイムスタンプとMACアドレスで生成）とランダムなUUIDv4がある。いずれも32桁
• 重複の心配がほぼないので、複数のデータベースで競合が起こらない。(分散できる）
• 表現できる値の範囲が2の128乗と膨大。
• UUIDv1はMACアドレスの情報を含む。セキュアなUUIDv7の使用を推奨する。

PostgreSQLの場合

• uuid_generate_v1(), uuid_generate_v4()が使用可能。

CREATE TABLE example (
    id UUID DEFAULT uuid_generate_v4() PRIMARY KEY,
    name TEXT
);

• ただし、拡張機能uuid-osspの有効化が必要。

CREATE EXTENSION IF NOT EXISTS "uuid-ossp";

いずれの対策を行うにしても必要なこと

• 認証・認可の仕組みは必須。（リソースのオーナーシップ確認）