認証（誰がログインしているか）と認可（その対象が本人のものか）は別物として扱い、認可はフロントの暗黙ルールやログイン通過ではなく、サーバ側のデータアクセス層のクエリ条件として強制する。最適化するのは「経路ごとに別実装でも所有者・テナント境界を必ず守ること」、避けるのは「読み取りだけスコープして書き込み経路を信頼境界の外に置くこと」。

判断基準

• 単体の更新・削除に所有者条件があっても、一括更新・並び替え・バルク削除・リダイレクト戻り先など別実装になりがちな経路は個別に確認する。ID だけで対象を突き合わせる一括更新は越境書き込み（IDOR）になりやすい。
• 削除・参照を URL やキーのパースで受ける経路は、許可プレフィックスへの限定と所有者一致の双方を入れる。任意パスを拾う実装は他人の対象へ波及する。
• 公開範囲やスコープのような状態は、フロントの「空なら全体」式の暗黙ルールに任せず、サーバ側で正規化して中間状態（API 直叩き・別クライアント・既存不正値）にも耐えさせる。
• アプリ層の事前チェックだけに頼らず、データアクセス層のクエリ自体に所有者条件を残す多層防御にする。フロントが意図通り制御できていても信頼境界はサーバに置く。

例外・限界 真に公開で誰でも読める対象は所有者条件が不要なことがある。その場合も「公開だから書き込みも自由」と混同しない。

検証 別ユーザーでログインし、他人の対象 ID やプレフィックス外のキーを各書き込み経路へ渡して、対象が変化せず拒否されることを確認する。単体操作のテストが通っていても一括・並び替え・削除は個別に検証する。

根拠（synthesize 元）

• 482 一括更新・並び替えAPIは所有者チェックが漏れやすい（IDOR検査観点）
• 489 クラウドストレージの削除APIはプレフィックス制限と所有者検証を必須にする
• 347 公開範囲のような状態表現はフロントの暗黙ルールではなくバックで正規化する
• 409 OAuth consent の redirect URL は保存元が自前でも検証してから使う
• 371 NestJS Guard: canActivate の false は403、NotFoundExceptionで404隠蔽