原則2 — 信じるものを、明示する

オープンリダイレクト — 行き先を、自サイト内の相対パスだけに絞った。
パストラバーサル — 連結後の実パスが、公開フォルダの中に収まっているかを確認した。
CORS の誤設定 — Origin を反射せず、登録済みの許可リストと突き合わせた。
SSRF — 宛先ホストの許可リストと、実IPでの内部帯遮断を両方行った。
認可(垂直・水平) — 明示的に許可された人以外は、既定で拒否した(deny-by-default)。
どれも、「危険なものを弾く」のではなく「安全と分かっているものだけを通す」という、同じ設計でした。

ブラックリスト(危険な文字列・パターンを弾く)が弱い理由は、共通しています——同じ意味を表す表記が、何通りもあるから。
127.0.0.1 は 127.1・0x7f000001・0177.0.0.1 とも書けます。../ は URL エンコードやパス正規化の揺れで別の見た目になります。<script> を弾いても onerror= が残ります。攻撃者は、意味は同じでも文字列としては違う表現を、無限に作れます。
一方、許可リストは「これだけを通す」と決めるので、表記の揺れに関係なく機能します(ただし、パストラバーサルのように実体で判定する——path.resolve した実パス、名前解決した実IP——ことが前提です)。

許可リストをさらに徹底したのが、認可で学んだ「既定は拒否」という設計でした。新しい機能を足すとき、何も書かなければアクセスできない状態から始める。許可を書き忘れれば「動かない」で気づけますが、拒否を書き忘れれば「気づかれないまま穴になる」——事故が起きたときの安全側に、既定値を倒しておく発想です。

「この値の“良し悪し”を、何と突き合わせて判定しているか?」を問います。
「危険な値のリストと比較している」なら、ブラックリストです——抜け道を疑う。
「許可された値のリスト/範囲と比較している」なら、許可リストです——その範囲が正しく狭いかを見る。
「特に何とも比較せず、そのまま使っている」なら——それがまさに、これまで見てきた穴そのものです。