問題

オブジェクトストレージ（GCS/S3 等）の削除エンドポイントで、クライアントが送ってきたオブジェクト URL を正規表現などでパース対象キーに変換し、認証だけ通っていれば削除する実装は危険。https://storage.example.com/<bucket>/(.+) のように (.+) で任意パスを拾うと、他ユーザーの URL（公開プロフィール等から取得可能）を投げるだけでそのオブジェクトを削除でき、バケット内の任意オブジェクトに波及しうる（IDOR / Broken Access Control）。アップロード側は profiles/ などにプレフィックス制限しているのに、削除側だけ制限が抜けるパターンが典型。

判断基準

• 認証（誰がログインしているか）と認可（そのオブジェクトが本人のものか）は別物。削除経路では必ず所有者検証を入れる。
• 対策の柱は二つ。(1) 削除可能なキーを所定プレフィックスに限定する。(2) ファイル名やパスにユーザー識別子を含め、リクエスト者と一致するキーだけ削除許可する。あるいは所有権判定を持つバックエンド側に削除を委譲する。
• 存在/非存在でレスポンス差分を返すと、オブジェクト列挙（存在確認）にも悪用されるため、所有者検証を入れて経路ごと塞ぐ。

検証方法

ユーザーA でログインし、ユーザーB のオブジェクト URL や所定プレフィックス外のキーを指定して削除 API を呼ぶ。所有者・プレフィックス検証があれば対象は削除されず拒否されることを確認する。アップロード経路にプレフィックス制限があっても削除経路は別実装になりやすいので個別にテストする。