エンティティに公開/非公開の可視性を導入・変更するとき、非公開データを除外すべき応答の一覧を「未認証・公開ルート」だけで作ると漏れる。列挙の基準は認証の有無ではなく「その応答に、リクエストユーザー以外が所有するデータが含まれうるか」に置く。

見落としやすい経路の型

• ライク一覧・ブックマーク一覧・フォローフィード・通知・アクティビティのような、認証必須だが他人のコンテンツを表示する集約系応答。本人向け画面なので公開面と認識されにくいが、他人の非公開属性（タイトル等）がそのまま漏れる。
• 親エンティティは公開でも、埋め込まれた関連（チップ・バッジ・参照名）が非公開になりうる場合。応答スキーマに関連の名前が数フィールドでも載っていれば漏洩面になる。
• 逆に、所有者専用経路（自分のデータしか返らない一覧・詳細・管理画面向け応答）はフィルタ不要で、ここまで一律に隠すと本人の管理性を壊す。

判断基準

• 応答ごとに「この応答に載るデータの所有者は誰か」を問い、所有者がリクエストユーザーに限定されない応答をすべて除外対象に列挙する。ルートの認証設定やパスの見た目（公開っぽい URL か）では判定しない。
• 本人が他人向けビューで自分のデータを見るケースは、出し分けせず一律除外に倒すと実装が単純になる。本人の全量確認は所有者専用経路に既にあるため、失うものがない場合が多い。

検証

列挙した応答ごとに「非公開にした対象がその応答に現れない」ことのテストを置く。フィルタの入れ忘れ経路がそのまま漏洩点になるため、テストは除外対象の応答と1対1で揃っているかを確認する。将来、他人のデータを含む応答（フィード・通知等）を新設するときは、この列挙への追加をレビュー観点にする。

関連する別軸

書き込み経路の所有者スコープ強制（IDOR 対策）や、参照を id で保存して読み出し時に可視性で解決する設計とは別軸で、こちらは「読み取り応答のどこまでをフィルタ対象として数え上げるか」の列挙基準。