—·
全てのコンテンツはAIによって生成されており、誤りが含まれる可能性があります。ご自身でご確認ください。
Chart.jsは、危険なオプションのバインディングやプラグインによって、不正なAPIデータをXSSの経路へ変え得ます。本稿では、いま棚卸しし強化すべき点を簡潔に示します。
Chart.jsがプロダクションのアプリに同梱されると、それは「単なるピクセル」ではありません。問題になるのは、JavaScriptの実行経路です。そしてWordfenceは、セキュアでないChart.jsのバージョンがプラグイン文脈に紛れ込み、既知のセキュリティ問題に対応するためのアップグレードが促された、実在の事例を記録しています。
（wordpress.org
重要なのは、Chart.jsのグラフはしばしばAPIデータを「そのまま」取り込む点です。ラベル、ツールチップ文字列、注釈テキスト、軸のタイトル、そしてプラグイン設定オブジェクトまで含まれます。これらの項目が安全でない形で結び付けられると、グラフの描画が、DOMベースのXSS（クロスサイトスクリプティング）への“最後の一押し”になる、あるいはプラグイン主導のコード実行チェーンの起点になる可能性があります。
DOMベースXSSとは、悪意あるペイロードがブラウザのDOM（Document Object Model）に存在し、そこで実行されるタイプのものです。典型的には、危険なDOM書き込み、またはスクリプト化されたプラグイン挙動を通じて発火します。
（cheatsheetseries.owasp.org
しかも、Chart.js本体が正しく動作していても、統合面はコアライブラリより広がります。具体的には次の要素が含まれます。
（1）依存関係のピン留めと、推移（トランジティブ）を含むサプライチェーンの整合性、
（2）信頼できない情報源からChart.js設定オブジェクトへ行われるオプションのバインディング、
（3）プラグイン登録と、プラグイン設定のレンダリング、
（4）リリース時の衛生状態（リリース管理）。
Chart.jsは明確にプラグインをサポートしており、あなたが使う部品を登録することを求めています。つまり「グラフ描画」は、設計として“合成可能なパイプライン”なのです。
（chartjs.org
Chart.jsの 2.9.4より前 の版で問題になっていた プロトタイプ汚染（prototype pollution） は、CVE-2020-7746 として追跡されました。これは、汚染されたプロトタイプによってオブジェクトのふるまいを操作し得る脆弱性として説明されています。
プロトタイプ汚染は攻撃クラスの一種で、攻撃者がJavaScriptのオブジェクト継承の振る舞いを変えます。その結果、アプリ側でそれらのオブジェクトを安全でない形で扱っていると、想定外の制御フローやセキュリティの迂回につながることがあります。
（security.snyk.io
npmエコシステムでは、サプライチェーンの侵害が引き続き観測されます。たとえば、悪意あるコードが検知またはフラグ付けされたパッケージが、レジストリから削除される（“除去される”）ようなケースです。Snykは、悪意あるコードを含むパッケージが、報告後にnpmのセキュリティチームによって 「Security Holding（セキュリティ保留）」 状態として取り扱われ、除去されるモデルを説明しています。
このモデルは、依存関係のピン留めやロックファイルの整合性と直結します。「latest」タグやルーズな範囲指定（ゆるいレンジ）は、インストールされるものを静かに変えてしまい得るからです。
（docs.snyk.io
Chart.jsに関連したセキュリティの教訓は、より大きなサプライチェーンの事故パターンにも現れています。Socket.devは、 chart.js-latest に関する悪意あるパッケージの分析ページを報告しています（運用上の要点は、依存関係の来歴と整合性です）。これは、あらゆるChart.js統合が悪用されている証拠ではないものの、攻撃者が人気のパッケージ名と配布チャネルを狙う方法を示しています。
（socket.dev
したがって「図表をコード実行として扱う」という立場は妥当です。パイプラインには実在のJavaScriptオブジェクト（オプション、データ配列、プラグインのコールバック）と、実在の依存関係の取得が関わっているためです。
Chart.jsは分かりやすいAPIを提供しています。つまり、グラフの設定オブジェクト（type、data、options）を作成し、それで描画するだけです。プラグインはそのパイプラインを拡張します。
もし設定の一部が信頼できない入力に由来しているなら、Chart.jsは、信頼できないデータとDOM操作、あるいはキャンバス描画ロジックをつなぐ“橋”になります。橋は神秘的なものではありません。オブジェクトのバインディング（結合）があるだけです。
「オプションのバインディング」とは、APIレスポンスの項目をChart.jsの options（多くの場合 data やプラグイン options も含む）へ写像して、設定オブジェクトを構築することです。これらの設定オブジェクトには文字列やネストされたオブジェクトが含まれます。ネストされたオブジェクトはしばしば、テキストのレンダリング、ツールチップの書式設定、注釈テキスト、そしてプラグインの描画へと渡ります。
プラグインはユーザー側が登録する仕組みなので、プラグイン作者がそれらの項目の使われ方を制御します。
（chartjs.org
攻撃の経路を仮定すると、次のような流れになり得ます。
信頼できないデータ → 設定フィールド → プラグインのレンダリング処理 → 危険なDOM操作（またはラッパーコンポーネントでの危険な文字列→DOM変換）→ DOM XSSが実行される
OWASPのDOMベースXSS予防ガイダンスは、信頼できないデータをDOMへ埋め込む最も基本的で安全な方法として、innerHTML のような手法ではなく、textContent のような安全なDOM代入を使うことを強調しています。
（cheatsheetseries.owasp.org
実運用では、危険性が最も高いのはラッパー層であることが多いです。React/Vueのコンポーネントは、HTML文字列でツールチップや凡例やラベルをレンダリングしたり、「リッチテキスト」を支えるためとしてHTMLを扱える値をチャートのプラグインへ渡したりする場合があります。アプリがチャート周辺でHTMLレンダリングを行う、またはReactの dangerouslySetInnerHTML やVueの v-html をどこかで使うなら、<canvas> に描画されるとしても、それを“実行ポイント”として扱ってください。
Chart.jsのプラグインは別個のnpmパッケージです。だからこそ、単一の巨大ライブラリの中だけで済む話ではなく、バージョン固定（ピン留め）、ロックファイルの整合性、そして許可リスト化（allowlisting）の重要度が一段と増します。Chart.jsはプラグイン登録の作法や、プラグインのエコシステムを明示しています。
（chartjs.org
プラグインをAPI（またはデプロイ間で変わり得る環境変数）から動的に選べるようにしているなら、実行を実行時の第三者コード経路へ委ねることになります。動的ローディングがなくても、プラグイン内部の推移依存が脆弱性や悪意あるコードを持ち込む可能性があります。これが「プラグインのサプライチェーン」リスクです。
そのリスクは机上の空論ではありません。Snykは、悪意あるパッケージがレジストリに入り、検知や保留（holding）後にnpmセキュリティチームによって「取り除かれる」ことがある、と説明しています。だからピン留めが効くのです。
（docs.snyk.io
CSP（Content Security Policy）はしばしば「XSS対策」として説明されますが、Chart.jsのパイプラインに対して効果を持つのは、「何が実行され得るか」をモデル化できている場合に限られます。図表（およびそのプラグイン）は通常、新しいスクリプトを直接生成しません。しかし、危険なHTML/DOMの挿入を引き起こすことで実行を成立させ得ます。挿入された内容は、インラインハンドラ（例：onerror、onload）を呼び起こしたり、スクリプトURLの実行を誘発したりします。CSPはこれらを止められますが、それはポリシーが必要なプリミティブをブロックできている場合に限ります。
OWASPのCSPチートシートは、CSPをスクリプト実行を制約し、注入による影響を抑える手段として位置付けています。
（cheatsheetseries.owasp.org
現実的な目標は、「CSPを入れる」よりも狭いです。あなたが欲しいのは、次の条件を満たすCSPです。
（a）デフォルトではインラインスクリプトを許可しない、
（b）注入されたマークアップによって誘発されるイベントハンドラの実行を防ぐ、
（c）DOM注入を“実行可能なペイロード”に転化させるほど広い script-src/object-src/base-uri の許可を避ける。
たとえばCSPが、unsafe-inline を許すような寛容な挙動（直接、または広い許可を通じて）を含んでいたり、運用デプロイを跨いで正しく管理するのが難しい寛容なナンスに依存していたりする場合、チャート経由のDOM注入はなお実行に至り得ます。
運用テストで確認してください。既知のHTML注入プローブ（innerHTML で挿入された場合に限って実行可能になるペイロード）を含むチャートのラベル文字列を用意し、実際のCSPヘッダーの下で、そのペイロードがスクリプト実行を引き起こせないことを確かめます。CSPは、汎用的なXSSシナリオだけでなく、ラッパー層で最も起こりそうな注入ベクター（ツールチップ/凡例のHTML、テンプレート文字列、あるいは「リッチテキスト」系プラグインオプション）に対して検証されるべきです。
チャート設定（データラベル、ツールチップ文字列、注釈、プラグインオプション）が信頼できない入力から導かれているなら、それをコードに近い“結び付いた状態”として扱ってください。API/DB/ユーザー入力がChart.jsの options やプラグイン設定へ変換される各地点を棚卸しし、そのうちどれほどHTMLを扱えるレンダリング経路や危険なDOM書き込みへ到達しているかを減らします。
強化は、描画の前に始まります。チームはしばしば「Chart.jsのXSSのシンク」を探しますが、Chart.jsパイプラインの早期失敗モードは別です。つまり、間違ったコードを入れてしまうことです。
依存関係のピン留めとは、package.jsonでパッケージの正確なバージョンを指定し、package-lock.json や yarn.lock のようなロックファイルを生成して、インストール結果を時間や環境を跨いで決定可能（デターミニスティック）にすることです。^4.0.0 のようなルーズなレンジは、依存関係のアップグレードを通じて新しい挙動や脆弱性を持ち込むことがあります。
Chart.jsにはセキュリティ上の履歴があります。CVE-2020-7746は2.9.4より前のChart.jsバージョンに影響し、プロトタイプ汚染の挙動と結び付いていました。
（security.snyk.io
運用としては、Chart.jsとChart.jsプラグインを定期的に更新し、「latest」に頼らないことです。Snykの悪意あるパッケージに関するドキュメントは、npmのセキュリティアクションが、検知後に悪意あるパッケージを除去し得る仕組みを説明しています。ビルドがルーズな範囲指定や実行時の取得を使っていると、レビューしたものと異なる成果物をインストールしてしまうことも起こり得ます。
（docs.snyk.io
ロックファイル整合性とは、CIで解決された“正確な依存関係”が、そのまま出荷されたものと一致することを確認することです。ここにこそ依存差分（diff）スキャナやCIチェックが置かれるべきです。ロックファイルが想定外に変わった場合、または承認されたアップグレード手順なしに変わった場合はビルドを失敗させます。
OWASPのCSPガイダンスは、サプライチェーンのドリフトを補うことはできません。また、ビルドがどのChart.js/プラグインのタールボールを入れたのかを検証することもできません。CSPはランタイムのブラウザ規則です。一方でロックファイルの来歴はビルド時点の来歴です。CSPチートシートのガイダンスは実行の抑止に焦点を当てており、コードの“差し替え”を検出するものではありません。
（cheatsheetseries.owasp.org
チームがCDNからChart.jsを読み込む場合、コードの来歴は第三者のホスティング層へ委ねられ、CSPもそのCDNスクリプトを許可する設定に依存します。対照的にローカルバンドルは、再現可能なビルドの中にサプライチェーンの面を閉じ込められます。
これもCSPとの相互作用の問題です。CDNを使うならCSPはそのソースを許可しなければならず、設定ミスは許可されたスクリプトの出どころを偶発的に広げてしまいます。OWASPのCSPガイダンスは、厳格なポリシー設定を強調しています。
（cheatsheetseries.owasp.org
チャート文字列のサニタイズだけをしているなら、まず最初の問題を解いていない可能性があります。依存関係のピン留めをセキュリティパイプラインの一部として扱ってください。Chart.jsとプラグインを厳密なバージョンでピン留めし、CIでロックファイルの整合性を担保し、そしてChart.jsプラグインチェーン全体で「latest」の意味論を避けます。
Chart.jsのプラグインは強力です。そしてその強さ自体が、運用上のリスクでもあります。Chart.jsはプラグインを“第一級の拡張”として位置付け、登録され、図表のライフサイクルに参加すると説明しています。
（chartjs.org
許可リスト戦略とは、許可するプラグインのパッケージをあなたが決め、その上で検証済みのコード経路からのみ登録することです。それ以外は、単に「使われない」のではなく、拒否されるべきです。
実アプリで見られがちな危険なパターンは次のようなものです。
・動的なプラグイン選択：UIが、サーバー提供のチャート「タイプ」、ユーザーの嗜好、機能フラグなどに基づき、読み込むプラグインを決める。
・ラッパーの“パススルー”設定：APIから受け取った汎用の chartConfig オブジェクトを、そのままChart.jsのコンストラクタやプラグインオプションへ渡す。
・無制限のプラグイン登録：モジュールが存在するかどうかだけで登録し、パッケージのバージョン、出どころ、想定する設定スキーマを検証しない。
Chart.jsのプラグインシステムは、これらのパターンを簡単に実現してしまいます。だからこそ許可リスト化は、後付けの思いつきではなく、意識的なアーキテクチャ判断にすべきです。
（chartjs.org
動的なプラグイン読み込みがなくても、文字列として扱うチャート設定フィールドは検証が必要です。スキーマ検証とは、バインドする前に型や許可された値を確認する規律です。
たとえば次のようにします。
・ラベル文字列はプレーンテキストとして受け付ける。
・ツールチップのテンプレートに想定しない文字が含まれる場合は拒否、または削除する。
・プラグインオプションを安全なサブセットに制限する（例：数値のみの閾値に限定）。
これはOWASPのDOM XSSガイダンスに直結します。最も安全なDOMの埋め込みは、innerHTML のようなHTML注入シンクではなく、textContent のような安全な代入に従うことです。もしプラグインやラッパーがHTMLを使うなら、境界でHTML注入を防いでください。
（cheatsheetseries.owasp.org
CSPは、注入されたスクリプト実行に対する最後のブラウザ側の防衛線です。OWASPのCSPチートシートは、未承認のスクリプト実行をブロックするディレクティブの作り方を説明しています。
（cheatsheetseries.owasp.org
チャートのパイプラインにHTMLのようなレンダリング（ツールチップ、凡例、外部ラベル）が含まれるなら、ツールチップはマークアップではなくテキストとして維持する方針にしてください。どうしてもマークアップを許す必要があるなら、サニタイズ済みのHTMLとして扱い、明確なサニタイザ方針を使うべきです。そしてCSPは厳格なままであるべきです。
許可リスト化は規律を強制します。プラグイン登録は、入力駆動ではなく“コンパイル時”またはコードレビュー済みの判断として行うことになります。そうすることで、攻撃者が渡した設定によって危険なプラグイン挙動が有効化されたり、不正なオプションが渡されて危険なDOM書き込みを行うことが起きにくくなります。
「今週」できる強化は現実的であるべきです。リリース前に失敗させるテストと、ランタイムの前に危険な依存関係を捕捉するスキャナが必要です。
多くのチャートリスクはDOM XSSに収束します。だからDOMに寄せたテストを使ってください。OWASPのDOMベースXSS予防ガイダンスは、安全なDOM代入パターンを強調しています。テストの“オラクル”をそこに据えましょう。つまり、信頼できない文字列が危険なシンク経由で挿入されないことを確かめるのです。
Jest + Playwrightの構成で、Chart.jsがDOMを触らないと“想定”するのではなく、振る舞いの不変条件（behavioral invariants） を検証してください。実ブラウザで確かめられる例は次の通りです。
・HTML実行経路がないこと：HTMLプローブを含むチャートのラベル/ツールチップ/注釈文字列を用意します。レンダされたチャートコンテナに想定外の要素や属性（注入されたノード、イベントハンドラ属性など）が増えないこと、そしてアラートや例外が発火しないことを検証します。
・危険なDOM挿入がないこと：ラッパー層（React/Vueコンポーネント、またはツールチップ/凡例レンダラー）を計測し、そのテストが innerHTML（または同等のDOMシンク）が信頼できないチャート文字列で使われていないかを検出できるようにします。最終DOMが“無害に見える”場合でも、該当フィールドでシンクが踏まれたら失敗させてください。
OWASPは、信頼できないデータに対する innerHTML のリスクを明確に警告しており、サニタイズまたは安全な代入を推奨しています。
（cheatsheetseries.owasp.org
CSPもテストハーネスに含めてください。同じPlaywrightシナリオを、プロダクションに近いCSPヘッダーを有効化した状態で実行し、注入されたマークアップが実行できないことを確認します。CSPをオフにすると通り、オンにすると落ちる（またはその逆）なら、どの層が実際に安全性を提供しているのかが分かります。ラッパーのサニタイズか、ブラウザ側の強制かです。
SBOM（Software Bill of Materials）は、ビルド内のコンポーネントを棚卸しします。ピン留めはSBOMを安定させ、スキャンは既知の脆弱性や“既に悪いと分かっている成果物”を検知する助けになります。
Snykの悪意あるパッケージに関するドキュメントは、パッケージがセキュリティ保留に移り、のちに削除され得ることを示しています。SBOMとスキャンの組み合わせで、ユーザーより先に検出できるのです。
（docs.snyk.io
別のスキャナであっても、統合パターンは同じです。
・CIの一部としてSBOMを生成する。
・SBOMをスキャンする。
・Chart.js、またはいずれかのチャートプラグインがブロック状態、もしくは未パッチの脆弱性を持っていればビルドを失敗させる。
Wordfenceの公開サポートスレッドでは、危険なChart.jsのバージョン（Chart.js 2.4.0が言及されていました）には既知のセキュリティ問題があり、アップデートを促していました。結果として、この問題はプラグインのエコシステムにおけるアップグレード行動として扱われました。
（wordpress.org
プロトタイプ汚染は「ただのバグ」ではありません。プロトタイプチェーンを汚染することで、JavaScriptオブジェクトの実行時の振る舞いを変えます。チャートのパイプラインでは、プラグイン作者やラッパーが options やネストされた設定オブジェクトを“単なるデータ”として扱いがちなため重要です。そして後になって、それらのオブジェクトを反復したり、マージしたり、分岐の判断材料にしたりします。結果として、脆弱なバージョンでチャートを描画していたチームは、想定外のオブジェクト挙動を避けるためアップグレードが必要になりました。これは「DOMサニタイザだけ」のアプローチではなく、「ピン留めしてパッチ適用する」ためのゲートに情報を与えます。
（security.snyk.io
これらのケースはあなたのアプリが脆弱であることを証明しません。しかし、運用上の教訓を示しています。つまり、チャートのセキュリティは依存関係と統合の継ぎ目で破綻し、対策はアップグレードと強化チェックの両輪である、という点です。
両方のゲートを使ってください。サプライチェーンのためのSBOMスキャンと、オプションバインディングやプラグイン描画の挙動のためのDOM寄りテストです。依存関係スキャンだけにすると、統合時注入の経路を見落とします。サニタイズだけにすると、バージョンのドリフトや悪意あるパッケージを見落とします。
今日からこのチェックリストを回してください。想定しているのは、典型的なChart.js統合です。React/Vueラッパー、APIからの動的設定、そしてサードパーティのプラグインが対象になります。
Chart.jsの入口（entrypoint）を棚卸しする
・リポジトリ内で new Chart(、Chart.register、およびプラグイン登録を検索する。
・チャートの data と options がどこから来るのか（API/DB、ユーザー入力、クエリパラメータ）を記録する。
・目標とする成果：チャートコンポーネントと設定組み立て関数の一覧。
依存関係を正確なバージョンへピン留めする
・Chart.jsと、使う各 chartjs-plugin-* を、ロックファイル上の正確なバージョンでピン留めする。
・承認済みのアップグレードPR以外で package-lock.json／yarn.lock が変わるビルドは拒否する。
SBOMを生成してスキャンする
・ビルドごとにSBOMを作り、スキャンする。
・Chart.jsの依存関係、またはチャートプラグインが悪意ある/保留状態だとフラグ付けされている、または既知の脆弱性状態にある場合はパイプラインを失敗させる。
・「悪意あるパッケージ／セキュリティ保留」の考え方を、運用上のスキャンルールとして実装する。
（docs.snyk.io
CSPを意識した統合テストを追加する
・CSPが、一般的な注入経路の実行を止められるほど厳格であることを確認する。
・厳格なポリシー目標のベースラインとして、OWASPのCSPチートシートのディレクティブを使う。
（cheatsheetseries.owasp.org
プラグイン登録を許可リスト化する
・静的でレビュー済みのリストからのみプラグインを登録する。
・外部設定から受け取った「プラグイン名」には何でも登録しない。
オプションのバインディング入力を検証する
・文字列フィールド（ラベル、タイトル、ツールチップ文字列など）について、許可される文字集合を検証するか、最大長と「マークアップなし」ルールを強制する。
・ラッパー層では安全なテキストレンダリングを優先し、信頼できないデータで innerHTML を避ける。
（cheatsheetseries.owasp.org
・HTMLをどうしても表示する必要がある場合はサニタイズし、CSPは厳格なまま維持する（なお、サニタイズをピン留めの代替だと見なさない）。
想定外の設定形状を拒否する
・options とプラグインオプションにはスキーマ検証を使う。
・許可していないキーやネストされたオブジェクトは遮断する。
・ラッパーの健全なデフォルト：React（またはVue）のラッパーでチャート設定propsを受け付けているなら、ツールチップと凡例はデフォルトで「テキストのみ」にする。HTMLレンダリングが忍び込みやすいのはツールチップです。
・段階的なプラグイン更新：専用のPRで1つずつプラグインを更新し、DOMテストを回す。複数のプラグイン更新を、関連のない機能作業と束ねない。
このチェックリストを実装すると、攻撃者が制御するチャート設定が実行へ変わる確率を下げられます。同時に、サプライチェーン上の出来事をユーザーへ届く前に検知可能にします。Chart.jsの設定を、バージョン固定とDOM/CSPゲートで強制される「特権の実行に結び付いたコード」として扱ってください。
今日（2026年3月23日）から 90日 以内に、チームは次の3つの方向でチャートのセキュリティを引き締めるはずです。
（1）ラッパーが進化するにつれ、プラグインの許可リスト化が一般化する。
（2）SBOMスキャンが、デプロイ後のセキュリティダッシュボードだけでなく、CIのより早い段階に組み込まれる。
（3）CSPポリシーが「広く許す」から「厳格でテストカバレッジあり」へシフトする。DOMベースXSSの失敗が、ブラウザテストで確実に捕捉されるようになってきているからです。
マネージャーやテックリード向けの実務的な方針として、次を推奨します。Chart.jsベースのUIを出荷する全チームに、SBOMスキャンゲートと、DOM XSSの回帰テストを追加し、チャート設定の変更またはチャートプラグインのアップグレードを含む機能作業をマージする前に必ず通すことを要求してください。
所有権も結び付けます。フロントエンドチームはDOMテストを持ち、ビルド/リリースチームはSBOMスキャンの強制を持ちます。
まずは、バージョン固定とプラグイン許可リストの統制を固めてください。そこが、「コード実行のような図表」が測定可能になるポイントです。あなたのパイプラインが、危険なチャート依存関係やプラグイン登録を止められるのか、それとも止められないのかが分かるようになります。