目次
JavaScriptで設定や利用者の属性を扱うとき、対象のオブジェクトにない値がどこから読まれるかを意識する必要があります。共有のプロトタイプが変更されると、入力を受け取った機能とは別の場所へ影響が広がる場合があります。
本記事は2026年10月18日にMDNとOWASPの一次資料を確認した実務解説です。特定の製品の脆弱性や事件の速報ではありません。設定画面を使う例と点検の順序は本サイトの提案です。依存ライブラリーごとの脆弱性の有無は、個別の公式情報で確認してください。
スポンサーリンク
値がない場合に継承先を探す仕組みを押さえる
JavaScriptでは、オブジェクト自身が持っていないプロパティを、プロトタイプをたどって探す場合があります。共有の継承先へ値が追加されると、自分では設定していない値が見える原因になります。MDNはこれをプロトタイプ汚染の仕組みとして説明しています。
影響を考える際は、汚染を起こす入口と、その値を使って重要な判断をする場所を分けます。動的なキーの書き込みがあっても、どこへ届き、どの値として使われるかで影響は違います。あらゆるマージ処理が必ず悪用できると一般化しないでください。
JSONの解析だけで直ちに共有のプロトタイプが書き換わる、と決めつけるのも不正確です。解析した後のコピー、マージ、パスによる代入などを含め、実際のデータの流れを追う必要があります。
出典：MDN JavaScript prototype pollution。
便利な設定のマージから調べる
本サイトの提案は、既定値へ外部の設定を重ねる処理から点検を始めることです。利用者の設定、URLの検索条件、外部APIの回答、保存した設定の読み戻しを対象にします。単純な一段の項目だけでなく、深いオブジェクトや、区切ったキーをパスとして扱う処理も確認します。
設定画面で色と表示件数だけを変えられるなら、その二つを明示して取り出す設計が考えられます。外部のオブジェクト全体を内部設定へ深くマージする必要があるかを見直してください。
設定がDBに保存されていることも、無検証でよい理由にはなりません。過去の入口や別サービスが書いた値を読み戻す段階でも、今の仕様へ合う項目と型だけを内部へ渡す方針にします。
スポンサーリンク
禁止する名前だけに頼らず形を限定する
MDNとOWASPは、入力の検証や不要なプロパティの拒否を対策として示しています。本サイトの提案は、入力の形をスキーマとして明示し、各階層で認める項目と型、深さ、件数を定義することです。
特定の名前だけを除去する処理では、別の経路や深い構造、後から追加した機能を見落とす場合があります。名前の拒否が必要な場面でも、業務上の項目を選んで取り出す設計と組み合わせます。
検証ライブラリーを入れたら、未知の項目が拒否されるのか、削除されるのか、そのまま通るのかを実際の設定で確認します。検証済みの結果ではなく元の入力を後段へ渡すと、入口の検証が利用されない場合があります。
認可の値は本人の属性として明示的に読む
重要な判断で、プロパティが存在するように見えることだけを根拠にしないでください。利用者の権限は信頼できる情報源から取得し、値が欠けているときに広い権限を与えない設計にします。
所有プロパティかを確認するObject.hasOwnなどは、継承した値を無意識に使わないための方法です。ただし、外部入力が持つ値なら、所有プロパティであっても本人へ権限を与える根拠にはなりません。どの情報源が決定できる項目なのかを別に判断します。
既定値を明示することも、欠けた値を継承先で探す場面を減らす助けになります。一方、既定値を設定するより前に危険なマージが動いていれば、原因を解決したことになりません。書き込み側と読み取り側の両方を点検します。
出典：OWASP Prototype Pollution Prevention Cheat Sheet。
スポンサーリンク
辞書にはMapや継承のないオブジェクトを検討する
任意の文字列をキーとして保存する辞書では、通常のオブジェクト以外の構造を選べる場合があります。Mapや、プロトタイプを持たないオブジェクトは、用途によって継承に伴う問題を避ける選択肢になります。
ただし、既存のライブラリーが普通のオブジェクトやそのメソッドを期待している場合、置き換えるだけでは互換性の問題が出ます。変換、列挙、保存、読み戻しを含めて確認します。安全な辞書から通常のオブジェクトへ無検証でマージし直す場所も見落とさないようにします。
必要な項目が決まっている設定と、任意のキーを保存する辞書は分けます。すべてを一つの汎用オブジェクトに詰め込まない方が、どこで外部のキーを扱うかを把握しやすくなります。
実行環境の防御を万能な修正にしない
Node.jsの--disable-protoは、一つの入口を減らすための機能です。MDNは、constructor.prototypeの経路などが残り、プロトタイプ汚染全体を防ぐものではないと説明しています。実行オプションを追加したことだけでアプリの入力処理を修正済みにしないでください。
組み込みのオブジェクトを凍結する方式にも、依存関係や初期化の順序との相性があります。本サイトの提案は、利用する基盤で必要性と互換性を確認し、段階的に導入することです。稼働中のサイトへ広い変更を無検証で加える方法は勧めません。
ブラウザーとサーバーでは、届く能力や影響が異なります。フロントエンドだけの問題と決めつけず、同じ入力をバックエンドやビルド用の処理でも使っていないかを確認します。
試験はプロセスを分けて後続への影響を見る
検証では、自分たちが管理する小さなデータを使い、予期しないキーや深い構造が拒否されるかを調べます。共有のプロトタイプを変更する試験を行うなら、隔離したプロセスで実施し、通常の試験群へ影響を残さないようにします。
処理がエラーになったことだけでは不十分です。例外の前に状態が変わっていないか、後続の別の要求が同じ既定値や認可結果を使うかを確認します。通常の入力が引き続き正しい設定として反映されることも照合します。
汚染が疑われる状況で、入力から特定のキーを削除しただけで実行中の共有状態が元に戻ったとは考えません。原因を除いたうえで、影響範囲と復旧方法を確認します。試験用の変更を本番の状態へ持ち込まないことが大切です。
表示設定を受け付ける仮想例で境界を確認する
仮想の管理画面が、表示言語と一ページの件数を受け付けるとします。本サイトの提案は、二つの項目を検証して新しい内部設定へ明示的に入れ、受信したオブジェクト全体を既定値へ重ねない構造です。入力の項目が増えても、許す業務機能が勝手に増えないようにします。
設定に認証の方式や外部送信の宛先が含まれるなら、同じ入力から変更できないことを確認します。未知の項目を捨てたつもりでも、後段が元の入力を参照していたら境界が保たれません。検証結果を使う経路と、元のデータが残る経路を区別します。
ネストした設定が必要な場合は、各階層へ同じ基準を適用します。最上位だけを調べて、内側を汎用のマージへ渡す方式では、深い入力で能力を増やせる場合があります。受け付ける深さと件数の上限も仕様に含めます。
スポンサーリンク
列挙とコピーの処理もレビュー対象にする
入力から必要な項目を選ぶ際、どのプロパティを列挙しているかを確認します。継承した値を含めてしまう処理と、自身の項目だけを使う処理では意味が異なります。既存のループや便利な変換関数が何を対象にするかを、公式仕様と小さな試験で確かめます。
本サイトの提案として、共通の変換関数へ任せる場合も、その関数が安全と判断した入力の形と、返す形を記録します。別の機能が後から任意のパスの指定を追加すると、以前の安全性の前提が変わる場合があります。汎用化した変更こそ、利用先を横断して確認してください。
診断結果には、危険な代入が見つかった箇所だけでなく、そこから重要な設定が読まれるまでの流れを残します。影響をまだ確認していない段階では、全利用者の権限が奪われるといった断定をせず、未確認の範囲を明確にします。
修正後に失敗側と正常側を両方比べる
入力の制限を強めた結果、正当な設定の保存が止まる場合があります。正常な設定の代表、未知の項目、境界の件数、古い保存形式を別々に確認し、拒否された理由が運用者へ分かるようにします。互換性のために無検証の旧形式へ自動で戻す処理を加えないでください。
復旧や移行で設定を読み直すときも、通常の画面と同じ境界を通すことを確認します。画面だけの対策では、管理ツールやバックアップからの再投入で元の問題が戻る場合があります。
スポンサーリンク
修正の単位は入力から重要な利用先まで
最初に外部のキーを扱う入口を探し、次に動的な代入やマージを追い、最後に重要な値の参照へつなげます。設定や認可への影響がないことを確認するには、この流れを途中で切らずに見る必要があります。
依存関係の修正も取り込みますが、ライブラリーを更新した後にアプリ独自の汎用マージを残していないかを確かめます。必要な項目を明示し、必要な場所でだけ使う構造へ近づけることが、将来の機能追加にも耐えやすい対策になります。
参考資料
以下の一次資料を2026年10月18日に確認しました。本文の仮想例と運用手順の提案は、資料の引用とは区別しています。
