XSS（クロスサイトスクリプティング）とは？3つの種類と開発者・運用者が取るべき対策を解説

反射型XSS（Reflected XSS）

反射型XSSは、利用者が送信したリクエストの内容を、Webアプリケーションがそのままレスポンスに含めて返してしまう場合に発生します。代表的なのは、検索キーワードやエラーメッセージなどを画面に表示する処理です。
攻撃者は、不正なスクリプトを含むURLを作成し、メールやSNSなどを介して利用者にクリックさせます。利用者がそのURLを開くと、サーバーがリクエスト内容をそのまま画面に出力し、結果として利用者のブラウザでスクリプトが実行されます。攻撃用スクリプトはサーバー側に保存されないため「反射型」と呼ばれます。

格納型XSS（Stored XSS／持続型XSS）

格納型XSSは、攻撃用スクリプトがWebアプリケーションのデータベースなどに保存され、それを閲覧した利用者全員のブラウザ上で実行されてしまうタイプです。掲示板、コメント欄、レビュー、プロフィール欄など、利用者の入力をそのまま他の利用者にも表示する機能で発生しやすくなります。
一度スクリプトが保存されると、削除されるまで複数の利用者に影響が広がる可能性があるため、反射型と比べて被害が拡大しやすい点が特徴です。

DOMベースXSS（DOM-based XSS）

DOMベースXSSは、サーバー側の処理ではなく、ブラウザ側で動作するJavaScriptに脆弱性がある場合に発生します。URLの`#`以降（フラグメント）やクエリ文字列など、クライアント側のJavaScriptが受け取った値を、適切な処理を行わずに`innerHTML`などへ書き込んでしまうと、利用者のブラウザ上でスクリプトが実行されます。
サーバーのレスポンスを介さないため、サーバーログだけでは検知が難しいケースもあります。シングルページアプリケーション（SPA）やリッチなフロントエンド実装が広まる中で、注意が必要なタイプです。

出力時のエスケープ（HTMLエスケープ）

XSS対策の中心となるのが、HTMLとして出力する際のエスケープ処理です。利用者から受け取った文字列を画面に表示するとき、`<` `>` `&` `"` `'` などの記号をHTMLエンティティに変換することで、ブラウザがスクリプトとして解釈することを防ぎます。
サーバーサイドでの簡易例（PHP）：
```php
echo htmlspecialchars($userInput, ENT_QUOTES, 'UTF-8');
```
クライアントサイドの例（JavaScript）：
```js
// innerHTML ではなく textContent を使い、HTMLとして解釈させない
const el = document.getElementById('output');
el.textContent = userInput;
```
出力先がHTML本文か、属性値か、URLか、JavaScriptコンテキストかによって必要なエスケープ処理が異なる点にも注意が必要です。OWASPの「XSS Prevention Cheat Sheet」では、コンテキスト別の出力エンコード方針が整理されています。

入力値のバリデーション

入力値の段階で、想定する形式や文字種に絞り込むこと（許可リスト方式）も有効です。たとえば、数値しか受け取らないフィールドであれば数値のみを許容し、メールアドレスであれば形式チェックを行います。
ただし、入力時のバリデーションだけではXSSを防ぎきれないため、出力時のエスケープと組み合わせて利用することが重要です。

Cookieのセキュリティ属性

XSSによってJavaScriptからセッションCookieが読み取られると、アカウント乗っ取りにつながります。Cookieには次のような属性を付与することで、リスクを軽減できます。

セッションを管理するCookieには、原則として`HttpOnly`と`Secure`を付与し、用途に合わせて`SameSite`属性も設定することが推奨されます。

CSP（Content Security Policy）の活用

CSPは、ブラウザに対して「どこから読み込んだスクリプトやリソースの実行を許可するか」を指定するための仕組みです。HTTPレスポンスヘッダーで設定し、不正に挿入されたインラインスクリプトや外部スクリプトの実行をブラウザ側で抑止できます。
最小限の例：
```
Content-Security-Policy: default-src 'self'; script-src 'self'
```
上記の例では、自サイト（`'self'`）から読み込んだスクリプトのみを許可し、インラインスクリプトや外部スクリプトの実行を制限します。実際の運用では、利用しているライブラリや広告、解析ツールなどとの兼ね合いを確認しながら、段階的にポリシーを厳格化していくことが現実的です。
CSPはXSSの影響を軽減する有効な手段ですが、単独で全てを防げるものではありません。出力時のエスケープなどの基本対策と組み合わせて利用することが重要です。

フレームワーク利用時の注意点

ReactやVue、Angularといったモダンなフレームワークでは、テンプレート内に変数を埋め込む際に自動的にエスケープが行われる仕組みが備わっていることが一般的です。一方で、次のような書き方をすると、自動エスケープを回避してしまい、XSSの原因になることがあります。

• Reactの`dangerouslySetInnerHTML`
• Vueの`v-html`
• AngularでサニタイズをバイパスするAPI

フレームワークの自動エスケープに依存するだけでなく、HTMLを動的に組み立てる箇所では、本当にHTMLを差し込む必要があるのかを設計段階で見直し、必要な場合は安全なライブラリでのサニタイズを併用することが望まれます。

WAF（Web Application Firewall）による検知・遮断

WAFは、Webアプリケーションへの通信を監視し、攻撃と疑われるリクエストを検知・遮断する仕組みです。XSSに代表される代表的な攻撃パターンへのシグネチャを備えていることが多く、既存システムの前段に設置することで、想定外の攻撃リクエストをブロックする効果が期待できます。
ただし、WAFはあくまでも防御層の一つであり、アプリケーション側の脆弱性そのものを修正するものではありません。アプリケーション側の対策と組み合わせて利用することが前提となります。

脆弱性診断・ペネトレーションテスト

実装後のWebアプリケーションに対しては、第三者による脆弱性診断やペネトレーションテストを実施することで、開発時に見落とした脆弱性を発見しやすくなります。
特にXSSは、画面遷移や入出力箇所が多くなるほど見落としが発生しやすくなる脆弱性です。リリース前や、大きな機能追加・改修のタイミングで定期的に診断を行うことが望ましいといえます。

ライブラリ・フレームワークの継続的なアップデート

利用しているフレームワークやライブラリに、XSS関連の脆弱性が報告されることもあります。アップデートの情報を定期的に確認し、必要なバージョンアップを計画的に行うことが重要です。

セキュリティ教育・コードレビュー体制

XSSは、コードの書き方一つで埋め込まれてしまう脆弱性です。開発者に対するセキュアコーディングの教育や、コードレビューでXSSの観点を含めることで、リリース前に脆弱性を発見しやすくなります。