JavaScript脆弱性診断とは？XSS対策から診断の進め方まで分かりやすく解説

JavaScriptはほぼすべてのWebサイトで動いています。

だからこそ、攻撃者が最初に狙うのもJavaScriptです。

2024年のpolyfill.io事件では、多くのサイトが利用していたブラウザ互換ライブラリが悪性スクリプトの配信経路として悪用され、10万以上のサイトが影響を受けました。

自社で書いたコードだけを守っていれば安全、というわけにはいかない現実があります。

「自動ツールだけで十分なのか」「どこから診ればいいのか」。

この記事では、1,000件超の診断実績を持つセキュリティエンジニアの知見をもとに、JavaScript脆弱性診断の基本から診断の進め方まで解説します。

JavaScript脆弱性診断とは？なぜ必要なのか

クライアント側コードの脆弱性を発見し、情報漏洩や改ざんを防ぐ

JavaScript脆弱性診断とは、ブラウザ上で動くJavaScriptが関与する脆弱性を発見・評価する検証です。

JavaScriptはブラウザ側で実行されるため、悪意ある攻撃者に操作されやすいという特性があります。

診断を通じて実害につながる攻撃経路を潰すことで、情報漏洩やサイト改ざんを防ぎます。

診断対象には、以下のような脆弱性が含まれます。

JavaScript脆弱性診断は、Webアプリケーション診断全体の中で「クライアント側の実行コード」と「外部ライブラリなどの依存コンポーネント」の問題点に焦点を当てる位置付けです。

本番サイトで実行されるJavaScript全体が診断対象

診断対象となるJavaScriptコードは「本番サイトで配信・実行されるJavaScript全体」です。

具体的には、以下の3つに分類されます。

診断対象となる処理としては、入力値検証や出力エスケープ、認証・認可、セッション管理、API通信なども対象に含まれます。

特に依存関係（npmなど）は、脆弱性の混入だけでなく、ソフトウェアの供給経路そのものを狙うサプライチェーン攻撃のリスクもあるため、診断対象に含めておく必要があります。

一方、プラットフォーム診断やOSやサーバー機器の診断、非JavaScript言語の脆弱性は対象外です。

被害は増加中。診断未実施が取引リスクになりつつある

2024年、ブラウザ互換ライブラリ「polyfill.io」のドメインが中国企業に売却され、悪性JavaScriptの注入に悪用されました。

セキュリティ企業Sansecの調査では、10万以上のサイトが攻撃対象となったことが判明しています。

自社で書いたコードだけを守っていれば安全、という前提が崩れた出来事です。

JavaScriptを使っているサイトであれば、どこでも起きうる話です。

もっとも頻繁に発見される脆弱性は「XSS（クロスサイトスクリプティング）」です。

IPA（情報処理推進機構）の統計では、Web脆弱性の届出の57%を占め、累計5,681件にのぼります。

2025年10〜12月だけでも88件の届出がありました。

情報漏洩による損害賠償、ブランドへのダメージ、サービス停止による機会損失。

被害はどれも甚大です。

近年さらに問題になっているのは、「診断を受けていない」こと自体が取引に影響するケースが増えていること。

取引先からの証明要求に対応できず、商談が止まるという話は珍しくなくなっています。

実際の診断はどう進む？手法の使い分けと4ステップ

リスクの把握ができたところで、次は診断の進め方です。自動・手動の使い分けという手法面と、ヒアリングから再診断までの4ステップを順に解説します。

自動診断だけでは不十分。手動が必要な場面とは

自動ツールはnpmパッケージの既知脆弱性チェックや、基本的なXSSパターンの検出は得意です。

ただ、ブラウザ内のDOM操作を起点に発生するDOM-based XSSのようにブラウザ内で完結する脆弱性は、自動検出が困難です。

手動診断が力を発揮するのは、こうした「ツールに任せられない」場面です。

決済処理のJavaScriptで金額計算のステップを意図的にスキップしたり、フォームの検証ロジックをブラウザ側で無効化したりといった「正常な手順を踏まない操作」による脆弱性は、人が実際に操作して初めて発見できます。

ユーザー入力からページに直接HTMLを書き込むような危険なDOM操作に至るデータの流れを実アプリの挙動で追う作業も、ツールには任せられません。

自動診断と手動診断の違いについては、以下の記事で詳しく解説しています。

あわせて読みたい

脆弱性診断における「手動診断」とは？特徴やメリットをわかりやすく解説

脆弱性診断には、大きく「自動診断 or 手動診断」の2種類があるのですが、自動化ツールが普及している現代、なぜ“人間の手による診断”が求められるのでしょうか。 自動診断は多くのシステムで広く導入されており、ツールを使って効率的に脆弱性を検出する手法です。この方法は短時間で多くの部分をチェックできる

なお、診断の範囲はログイン・決済・管理画面などの重要機能を優先して決めます。

予算に制約がある場合も、決済や個人情報まわりは省略すべきではありません。

ヒアリングから再診断まで4ステップの流れ

JavaScript脆弱性診断は、以下の4ステップで進みます。

ヒアリングで診断範囲とテスト環境を確認する

ヒアリングで最初に確認するのは、テスト環境の有無です。

本番環境しかない場合は、診断の対象範囲を最初に絞ることになります。

診断を効果的に進めるために、以下を準備しましょう

自動スキャンと手動検証で脆弱性を洗い出す

まず、自動診断ツールで広範囲のスキャンを行い、世界標準のWebセキュリティリスクリスト「OWASP Top 10」などの既知脆弱性を効率的に検出します。

続いて、手動診断で権限外操作や不正な権限昇格など、自動ツールでは発見困難な脆弱性を人の目で確認します。

深刻度と改修優先度を報告書で整理する

報告書は技術担当だけでなく経営層にも読める形で作っています。

深刻度の高い問題は、なぜビジネス上のリスクになるのかを言葉で説明しないと、対応の優先順位が現場任せになってしまいます。

診断結果報告書には、発見された脆弱性の詳細、深刻度評価、対策提案を盛り込みます。

どの脆弱性から対応すべきか、予算や工数を考慮した実現可能な改修計画をご提案します。

修正後の副作用も確認する再診断

修正したつもりが別の箇所に問題を生んでいた、ということは実際にあります。

再診断はそのための確認でもあります。

単に脆弱性が修正されたかだけでなく、修正によって新たな問題が発生していないかも確認します。

どんな脆弱性が見つかる？主要4種の手口と被害

JavaScript脆弱性診断で発見される主要な脆弱性は、以下の4つです。

それぞれの定義と攻撃手法、被害の内容を解説します。

XSS（クロスサイトスクリプティング）

「ReactやVueを使っているから、XSSは大丈夫」と思っている開発者は多いですが、実際には最も多く届出られている脆弱性です。

フレームワークが自動で特殊文字を無害化するエスケープ処理を行うのはテンプレート内の出力のみです。

dangerouslySetInnerHTML（ReactでHTMLを直接出力する機能）や v-html（VueでHTMLを直接出力する機能）を使えば防御は機能しません。

XSSとは、Webアプリケーションに悪意あるスクリプトを挿入し、ユーザーのブラウザで実行させる攻撃です。

Cookie盗難やログイン状態を乗っ取るセッションハイジャック、個人情報の窃取に悪用されます。

IPA「ソフトウェア等の脆弱性関連情報に関する届出状況」では、ウェブサイト脆弱性の累計における種類別割合として「XSSが57%」を占めており、もっとも頻繁に発見される脆弱性です。

XSSには3種類あります。

DOM-based XSSはJavaScriptがDOM操作する際に発生します。URLパラメータやブラウザ内にデータを保存するlocalStorageの値を直接innerHTMLへ渡すことで成立します。

Stored XSSは悪意あるスクリプトがデータベースに保存され、そのページを閲覧した全員に影響を与えます。

Reflected XSSはURLなどに含めた悪意あるスクリプトがレスポンスに反射されて実行されます。

CSRF（クロスサイトリクエストフォージェリ）

Cookieの送信先を制限するSameSite属性を設定しているから安心、と判断している現場もありますが、それだけでは完全な防御にはなりません。

LaxモードではGETリクエストを使うCSRF攻撃を防げないためです。

CSRFとは、ユーザーが意図しない操作を実行させる攻撃です。

パスワード変更や個人情報の書き換え、購入処理の実行といった形で悪用されます。

典型的な攻撃例は、罠サイトに仕込んだフォームから、ユーザーが認証済みのサイトへ不正なリクエストを送りつける手口です。

対策としては、サーバーとブラウザだけが共有する使い捨ての認証コード「CSRFトークン」の実装が基本です。

状態を変更するリクエストにCSRFトークンを付与し、バックエンドで検証します。

JavaScriptでfetchやXHRを使う場合は、ヘッダやボディにトークンを確実に載せる必要があります。

また、SameSite Cookie属性を追加防御として利用できますが、完全な防御ではありません。

SQLインジェクション

「SQLインジェクションはサーバー側の問題では？」JavaScript診断の場で、この疑問はよく出ます。

それは、よくある誤解です。

攻撃者が制御できるパラメータは、最終的にJavaScriptを経由してサーバーに届きます。

入力の起点を見ずに、バックエンドだけを守っても意味がありません。

SQLインジェクションは、データベースを操作するSQL文に悪意あるコードを挿入する攻撃です。

データベースを不正に閲覧・改ざん・削除されるほか、情報漏洩やシステム乗っ取りにまで発展することがあります。

JavaScriptがAPIへ渡すパラメータは「攻撃者が制御できる」前提で設計し、バックエンドではSQLの命令と入力値を分離して安全に処理するプリペアドステートメントを使うのが基本です。

典型的な攻撃例は、検索フォームに ‘ OR ‘1’=’1 といった入力を行うことで、すべてのデータを取得できてしまう、という具合です。

対策としては、バックエンドでのプリペアドステートメント使用、JavaScriptとサーバー側での入力値検証、データベース操作を安全に抽象化するORMの活用が挙げられます。

オープンリダイレクト

オープンリダイレクトは、地味に見えて実はフィッシングメールの精度を格段に上げる脆弱性です。

「正規サイトのURL」に見えるリンクを踏んだ先が、まったく別のサイトへ誘導されます。

ユーザーが疑う理由がありません。

オープンリダイレクトとは、任意のURLへ強制的に転送させる脆弱性です。

フィッシングサイトへの誘導やマルウェア配布サイトへの誘導に悪用されます。

典型的な攻撃例は、URLパラメータに悪意あるURLを指定し、転送先を検証しないままページ遷移させる手口です。

対策としては、リダイレクト先をあらかじめ許可したURLに限定するホワイトリスト検証が必要です。

また、相対パスの使用により外部URLへのリダイレクトを避けることも有効です。

脆弱性を防ぐには？4つの効果的な対策方法

主な対策方法は以下の4つです。

入力値検証で攻撃の入り口を塞ぐ

入力値検証は、悪意ある入力を受け付けないための第一の防御です。

基本的な実装方法として、以下があります。

リッチテキストエディタなど、HTMLを扱う必要があるケースでは、危険なコードを取り除くHTMLサニタイズライブラリDOMPurifyなどを使用します。

DOMPurifyは危険な要素を除去して「クリーンなHTML」を返すことでXSSを防ぎます。

出力エスケープでXSSを根本から防ぐ

出力エスケープは、XSSを防ぐための根本的な対策です。

エスケープとは、< や > などのHTML特殊文字を無害な文字列に変換する処理のことです。これにより、悪意あるコードが「スクリプト」ではなく「ただのテキスト」として扱われます。

具体的な実装方法は以下の通りです。

CSPで不審なスクリプトの実行をブロックする

CSP（Content Security Policy）とは、実行を許可するスクリプトやリソースをブラウザに指定するセキュリティ機能です。

CSPを導入することで、XSSの実行を防ぎ、想定外のスクリプトが動くことを困難にします。

HTMLに直接書いたJavaScriptの実行制限も可能です。

基本的な設定例としては、script-srcに許可ドメインのリストを設定して想定外のスクリプト読み込みをブロックする方法や、リクエストごとに発行する使い捨てコード（nonce）で正規スクリプトだけを許可するnonceベースの設定があります。

HTTPヘッダーまたはmetaタグで設定します。

個々の対策を支えるセキュアコーディングの土台

個々の対策を実践する前に、土台となる考え方があります。

それがセキュアコーディングの原則です。

日々の開発で意識しておくだけで、セキュリティの底上げにつながります。

これらを開発チーム全体で共有し、コードレビューやテストの中で確認し続けることが、セキュアなシステムへの道です。

まとめ：JavaScript脆弱性診断はnpmスキャン5分から始める

JavaScript脆弱性診断の基本から、診断の進め方、主要な脆弱性、対策方法までを解説してきました。

まず明日できることから始めるなら、npmのパッケージスキャンを5分で走らせることです。

npm audit コマンドを実行するだけで、利用中のライブラリに既知の脆弱性がないかを一覧できます。

その先に手動診断が必要かどうかは、その結果を見てから判断すれば十分です。

コードを実行せずに問題を検出する静的解析も組み合わせたい場合は、ソースコード診断も選択肢に入ります。