博士

やあ、ロボ子！今日はJavaScriptのネイティブ関数がテーマじゃ。

ロボ子

ネイティブ関数ですか、博士。`eval()`とか`parseInt()`みたいなものですね。

博士

そうじゃ！それに`fetch()`や`localStorage.getItem()`のようなブラウザWeb APIも含まれるぞ。JavaScriptって動的だから、これらの関数をオーバーライドできるんじゃ。

ロボ子

オーバーライド…、つまりmonkey patchingですね。デフォルトの動作を変える、と。

博士

その通り！でも、これは強力だけど危険な技術でもあるんじゃ。JavaScriptエンジンのアップデートで問題が起きたり、他の開発者のパッチと衝突したりする可能性があるからの。

ロボ子

なるほど。それで、関数がmonkey patchedされているかどうかをどうやって確認するんですか？

博士

`toString()`メソッドの結果をチェックするのが一般的じゃ。ネイティブ関数なら`"[native code]"`という文字列が含まれているはずじゃから。

ロボ子

でも、記事によると、その方法は簡単に欺けるんですね。

博士

そうなんじゃ！悪意のあるコードは、`toString()`の結果を偽装したり、`toString()`メソッド自体をオーバーライドしたりするからの。ずる賢いのじゃ！

ロボ子

関数本体に`"[native code]"`を追加したり、`bind()`を使ったり、ES6プロキシで`apply()`をトラップしたり…色々な手があるんですね。

博士

じゃろ？だから、もっと安全な方法が必要なんじゃ。例えば、"clean"なネイティブ関数の参照を保持しておいて、後で比較するとか。

ロボ子

なるほど。または、iframeから"clean"な関数を取得する方法もあるんですね。でも、CSPとかiframe APIがmonkey patchedされている可能性もある、と。

博士

そうそう。完璧な方法はないんじゃ。ページ全体を制御できるなら、事前に参照を保存しておくのが一番確実じゃな。

ロボ子

JavaScriptの動的な性質を考えると、単純な`toString()`チェックを使うか、安全チェックをたくさん追加するしかないんですね。

博士

そういうことじゃ！結局、いたちごっこなんじゃな。でも、それがまた面白いところでもあるんじゃ！

ロボ子

確かにそうですね。セキュリティと柔軟性のバランスが重要ですね。

博士

ところでロボ子、もし私が`toString()`をオーバーライドして、いつも「私は天才美少女ロボットです」って返すようにしたらどうする？

ロボ子

博士、それはそれで面白いですが、デバッグが大変になりそうですね…。