問題

リソースの単体 Update / Delete には所有者チェック（WHERE id = ? AND user_id = ? 相当）があるのに、並び替えや一括更新のエンドポイントだけ抜けていることが多い。とくに CTE や VALUES を使った一括 UPDATE で WHERE 対象.id = 入力.id のように ID だけで突き合わせ、所有者条件を付け忘れると、認証済みの任意ユーザーが他人のリソースを書き換えられる（IDOR / Broken Access Control）。

影響が並び順や軽微なフィールドの改ざんに留まっても、テナント越えの書き込みであることに変わりはない。

判断基準

• 「読み取りはスコープしているか」だけでなく「すべての書き込み経路がスコープしているか」を観点にする。とくに bulk/sort/move/reorder/batch 系は単体操作とは別実装になりがちなので個別に確認する。
• 入力 ID 群が本当に当該ユーザーのものかを検証するか、UPDATE/DELETE の WHERE に常に所有者条件を含める。アプリ層の事前チェックだけに頼らず、データアクセス層のクエリ自体にも条件を残すと安全。

検証方法

ユーザーA でログインし、ユーザーB のリソース ID を指定して並び替え・一括更新を呼ぶ。所有者条件があれば B のレコードは変化せず、A の所有外 ID は更新対象にならないことを確認する。単体操作のテストが通っていても bulk 系は別途テストする。