サニタイズとは？エスケープ・バリデーションとの違いと実装方法を解説

本記事には広告が含まれています

2025/03/022026/10/28

Webアプリケーションを安全に運用するためには、サニタイズ（sanitize）の理解と適切な実装が不可欠です。

先に結論をお伝えすると、サニタイズとは「外部から受け取ったデータを無害化する処理」のことですが、それだけでWebアプリを守ることはできません。実務では「入力時のバリデーション」「出力先に合わせたエスケープ」「プリペアドステートメント」などを組み合わせて使うのが基本です。

本記事では、サニタイズの基本概念やエスケープ・バリデーションとの違い、代表的な攻撃手法と対策、言語・フレームワーク別の具体的な方法、Cookieのセキュリティ設定まで徹底解説します。Web開発者はもちろん、セキュリティ対策を強化したい方も必見です。

サニタイズ（sanitize）とは？意味と目的

サニタイズ（sanitize）とは、主にWebアプリケーションやソフトウェア開発において、外部から受け取ったデータに含まれる不正・危険な要素を取り除き、無害化（安全化）する処理を指します。英語の「sanitize」はもともと「消毒する・衛生的にする」という意味で、データを「消毒」して安全な状態にするイメージから、この名前で呼ばれています。

たとえば、掲示板の投稿欄に <script> タグが書き込まれたとき、そのタグを削除したり、ただの文字として表示されるように変換したりする処理がサニタイズにあたります。

ただし、サニタイズはセキュリティ対策の一部にすぎず、それだけでは不十分です。例えば、攻撃者が意図的に悪意ある文字列を埋め込んだ場合、「そもそも入力時点で危険なデータを受け取らない（バリデーション）」ことや、SQLインジェクション対策として「プリペアドステートメント（Prepared Statement）」を使うことなどが、より根本的で強力な防御策となります。

「サニタイズ」という言葉があいまいに使われる理由

「サニタイズ」は、人や資料によって指している範囲が異なる言葉です。危険な文字を削除する処理だけを指す場合もあれば、エスケープ（変換）や入力チェックまで含めて「サニタイズ」と呼ぶ場合もあります。

この言葉のあいまいさが原因で、「入力時にとりあえずサニタイズしておけば安全」という誤解が生まれやすくなっています。IPA（情報処理推進機構）の「安全なウェブサイトの作り方」でも、XSS対策は「出力する際のエスケープ処理」、SQLインジェクション対策は「プレースホルダ（プリペアドステートメント）での組み立て」というように、攻撃ごとに具体的な処理として説明されています。本記事でも、何をいつ行う処理なのかを区別して解説していきます。

サニタイズ・エスケープ・バリデーションの違い

混同されやすい3つの処理を、まず表で整理します。

処理	主なタイミング	やること	例
バリデーション	入力を受け取ったとき	想定した形式・範囲かを検証し、外れていれば拒否する	郵便番号欄に7桁の数字以外が来たらエラー
サニタイズ	入力時または保存・出力の前	危険な要素を削除・置換して無害化する	投稿HTMLから `<script>` や `onclick` 属性を取り除く
エスケープ	出力する直前	出力先で特別な意味を持つ文字を、ただの文字として扱われるように変換する	`<` を `<` に変換してHTMLに出力

サニタイズとバリデーションの違い

サニタイズ: 受け取ったデータを無害化する（想定外のコードを削除・変更する）処理。
バリデーション: 受け取ったデータが想定している形式・範囲に収まっているかを検証し、危険なデータをそもそも受け取らないようにする取り組み。

たとえば、XSSやSQLインジェクションを防ぎたい場合でも、危険なデータをエスケープ・サニタイズする前に、「そのようなデータを受け付けない」ようにすることが理想です。

ただし、バリデーションで防げるのは「形式が決まっている項目」までです。名前・コメント・問い合わせ本文のように自由入力を受け付ける項目では、記号を含む正当な入力（例：「O’Reilly」という姓や、プログラムの質問文）も多いため、バリデーションだけで危険な文字を締め出すことはできません。そのため、出力時のエスケープは、バリデーションの有無にかかわらず必ず行う必要があります。

サニタイズとエスケープの違い

サニタイズ（sanitize）
受け取ったデータを「悪意あるコードが実行されないように削除・置換する」処理の総称です。場合によってはエスケープもサニタイズに含まれるとされることがありますが、厳密にはサニタイズとエスケープは異なる概念と考えるのが望ましいです。
エスケープ（escape）
特定のコンテキスト（HTML、SQL、JavaScriptなど）で、特殊文字が悪用されないように変換する処理を指します。データの中身は削らず、「意味」だけを打ち消すのが特徴です。
例：
- HTMLエスケープ: <script> を <script> に変換する
- SQLエスケープ: シングルクォート ' を ''（クォートを2つ重ねる）に変換する。MySQLなど一部のデータベースでは \' も使われる

なお、SQLエスケープは文字コードやデータベースの種類によって正しい方法が変わり、手作業では漏れが起きやすい処理です。SQLインジェクション対策では、エスケープを自分で書くよりも、後述するプリペアドステートメントを使うのが基本です。

「入力時にまとめてサニタイズ」が危ない理由

「入力を受け取った瞬間に、危険そうな文字を全部消しておけば安心」と考えがちですが、この方法には次のような問題があります。

出力先によって危険な文字が違う：HTMLでは < や "、SQLでは '、シェルでは ; や | が危険です。入力の時点では、そのデータが将来どこに出力されるかすべてを予測できません。
正しいデータまで壊れる：「O’Reilly」の ' を消すと別の名前になり、ユーザーの入力内容が勝手に書き換わってしまいます。
二重エスケープが起きる：入力時に < へ変換したデータを、出力時にもう一度エスケープすると、画面に「<」という文字がそのまま表示されてしまいます。

そのため、入力時は「バリデーション（形式チェック）」、出力時は「出力先に合わせたエスケープ」と役割を分け、データ自体はなるべく元の形のまま保存するのが現在の定石です。HTMLの一部を許可したい場合など、削除型のサニタイズが必要な場面では、専用のライブラリを使います（後述）。

サニタイズが必要なケース

Webフォームからの入力
- ユーザーのフォーム入力にJavaScript等のスクリプトが埋め込まれていれば、XSS（クロスサイト・スクリプティング）などの攻撃に利用される可能性があります。
URLパラメータ
- 悪意ある文字列がURLパラメータに含まれることで、SQLインジェクションやコマンド・インジェクション等につながる恐れがあります。検索キーワードをそのまま「〇〇の検索結果」と画面に表示するページは、XSSの典型的な入り口です。
アップロードファイルの取り扱い
- アップロードされたファイル名やファイル自体に悪意あるコードが仕込まれていることがあります。サニタイズだけでは不十分な場合が多く、適切な検証（バリデーション）や実行権限の制限など、多面的な対策が必要です。
Cookieの値
- ユーザーが自由に書き換えられるCookieに、攻撃用スクリプトが含まれる場合もあります。Cookieの中身をHTML出力などに直接使用すると、XSSのリスクが生じます。
HTTPヘッダーや外部APIから受け取ったデータ
- User-AgentやRefererなどのリクエストヘッダー、外部サービスのAPIレスポンスも、攻撃者が中身を操作できる「外部からの入力」です。アクセスログの管理画面にUser-Agentをそのまま表示して、管理者のブラウザでスクリプトが動く、といった事例もあります。
データベースに保存済みのデータ
- 「自分のDBから取り出したデータだから安全」とは限りません。もとはユーザーが入力した値であれば、表示のたびにエスケープが必要です。保存された攻撃コードが後から表示されて発動するものを「格納型（持続型）XSS」と呼びます。

代表的な攻撃例と対策

Webアプリケーションの代表的なリスクをまとめた「OWASP Top 10」の2025年版でも、XSSやSQLインジェクションを含む「インジェクション（Injection）」は5位（A05:2025）に入っています。2021年版の3位からは順位を下げたものの、OWASPの集計では、テストしたすべてのアプリケーションで何らかのインジェクションの検査が行われ、CVE（公開された脆弱性）の件数も全カテゴリで最多とされており、今も対策が欠かせない分野です。

XSS（クロスサイト・スクリプティング）
- 攻撃例: フォーム入力やURLパラメータ、CookieにJavaScriptを仕込み、他の利用者のブラウザでスクリプトを実行させる。Cookieの盗難やなりすまし、偽のログインフォームの表示などに悪用されます。
- 対策:
  - HTMLエスケープやテンプレートエンジンの自動エスケープ機能を利用する。
  - そもそも入力値に危険なタグが含まれていれば弾く（バリデーション）。
  - Content Security Policy（CSP）で、実行してよいスクリプトの読み込み元を制限する（万一のときの被害を抑える保険）。
SQLインジェクション
- 攻撃例: SQL文の中にユーザー入力がそのまま挿入され、意図しないクエリ（DELETEやDROPなど）が実行される。ログイン画面のパスワード欄に ' OR '1'='1 のような文字列を入れて認証を突破する手口が有名です。
- 対策:
  - プリペアドステートメント（Prepared Statement）を使用する（サニタイズよりも強力かつ推奨される方法）。
  - フレームワークが提供するORM（Object Relational Mapping）や安全なDB操作機能を利用する。
  - アプリが使うDBユーザーの権限を必要最小限にし、万一の被害を小さくする。
コマンド・インジェクション
- 攻撃例: サーバでシェルコマンドを実行する際に、ユーザー入力が直接結合されることで任意のコマンドが実行される。
- 対策:
  - シェルへの直接的な文字列結合を避ける。可能であれば、外部コマンドを呼ばずに言語の標準機能やライブラリで処理する。
  - どうしても文字列を渡す必要がある場合、使用する文字を限定したホワイトリスト方式やエスケープを徹底する。
アップロードファイルを介した攻撃
- 攻撃例: 偽装された拡張子や危険なスクリプトを含むファイルがアップロードされ、サーバ上で実行されてしまう。
- 対策:
  - 拡張子チェックだけでなく、MIMEタイプの検証を行う。MIMEタイプは送信側で偽装できるため、ファイル先頭のバイト列（ファイルの中身）でも形式を確認するとより確実です。
  - サーバの設定でアップロードされたファイルを実行できないようにする。保存先は公開ディレクトリの外にするのが理想です。
  - 保存するファイル名はユーザーが付けた名前を使わず、サーバ側でランダムな名前に付け替える（../ を使ったディレクトリ移動などを防ぐ）。
  - ウイルススキャンやセキュリティゲートウェイの併用で危険なファイルを検出する。

サニタイズの具体的な方法

エスケープ処理
- HTMLやJavaScript、SQLなど、利用するコンテキストごとに適切なエスケープを行う。
- フレームワークによっては自動エスケープ機能があるため、積極的に活用する。
バリデーション（検証）
- 受け付ける入力値の形式・種類を明確にし、想定外のデータが送られてきた場合はエラーとする。
- 例: 数値のみを受け付ける項目に英字が含まれていればエラーとする、など。
- JavaScriptによるブラウザ側のチェックは利用者の使いやすさのためのものです。攻撃者はブラウザを通さずにリクエストを送れるため、同じチェックを必ずサーバ側でも行う必要があります。
ホワイトリスト方式
- 「この文字だけは許可する」という方式で入力値をフィルタリングする。
- 例: ユーザーIDの場合は、[a-zA-Z0-9_-] のみ許可し、それ以外は弾く。
- ブラックリスト方式（危険な文字だけを除外する）では、想定外の危険な文字が増え続ける可能性があるため、安全とはいえません。その点で、ホワイトリスト方式（安全な文字だけを許可する）のほうが望ましいとされています。
使用する言語やフレームワークが提供する機能の活用
- 例: PHPの htmlspecialchars() や filter_var(), Ruby on Railsの自動エスケープ機能, Pythonの html.escape(), Javaの PreparedStatement など。
- SQLインジェクション対策としては、プリペアドステートメント（Prepared Statement）の利用が推奨されます。

出力先ごとのエスケープ方法早見表

エスケープは「どこに出力するか」で方法が変わります。HTML用のエスケープをしたからといって、JavaScriptやURLの中で安全になるわけではない点に注意してください。

出力先	主な危険文字	対策
HTMLの本文	`<` `>` `&`	HTMLエスケープ（文字参照に変換）
HTMLの属性値	`"` `'` と上記	属性値を必ず `"` で囲み、クォートも含めてエスケープ
URL（href・srcなど）	`javascript:` などのスキーム	`http`／`https` で始まるURLだけを許可し、パラメータはURLエンコード
JavaScriptの中	`'` `"` `</script>` など	値を直接埋め込まず、JSON形式で渡すか `data-` 属性経由で受け渡す
SQL	`'` など	プリペアドステートメント（プレースホルダ）を使う
シェルコマンド	`;` `\|` `&` ` など	シェルを経由しない呼び出し方にする。やむを得ない場合は専用関数でエスケープ

言語・フレームワーク別の主な関数と機能

代表的な言語・フレームワークで使われる関数や機能をまとめました。自前で置換処理を書くより、これらの実績ある機能を使うほうが安全です。

スクロールできます

言語・環境	HTMLエスケープ	SQL	補足
PHP	`htmlspecialchars($s, ENT_QUOTES, 'UTF-8')`	PDOのプリペアドステートメント	入力チェックには `filter_var()`。`FILTER_SANITIZE_STRING` はPHP 8.1で非推奨
WordPress	`esc_html()` `esc_attr()` `esc_url()`	`$wpdb->prepare()`	入力の無害化に `sanitize_text_field()`、許可したHTMLだけ残すなら `wp_kses()`
Python	`html.escape()`、Django・Jinja2の自動エスケープ	DB-APIのプレースホルダ、ORM	外部コマンドは `subprocess` に引数をリストで渡す
Ruby on Rails	ERBの `<%= %>` が自動エスケープ	Active Recordのプレースホルダ	`raw` や `html_safe` はエスケープを無効にするため注意
Java	テンプレートエンジンの自動エスケープ、OWASP Java Encoder など	`PreparedStatement`	文字列連結でSQLを組み立てない
JavaScript（React など）	JSXの `{}` による埋め込みは自動エスケープ	（サーバ側で対応）	`dangerouslySetInnerHTML` や `innerHTML` を使う箇所は要注意

例として、PHPでの「出力時のHTMLエスケープ」と「プリペアドステートメント」の書き方は次のとおりです。

// 出力時のHTMLエスケープ
echo htmlspecialchars($comment, ENT_QUOTES, 'UTF-8');

// プリペアドステートメント（PDO）
$stmt = $pdo->prepare('SELECT * FROM users WHERE email = ?');
$stmt->execute([$email]);

SQL文の「形」を先に確定させ、ユーザーの入力値は後から「値」としてだけ渡すので、入力にどんな記号が含まれていてもSQLの構造が書き換わることはありません。PHP 8の新しい書き方については「PHP 8 新機能解説：ユニオン型・名前付き引数・Match 式から JIT まで」でも紹介しています。

HTMLの入力を許可したい場合は専用のサニタイザーを使う

ブログのコメント欄やリッチテキストエディタのように、太字やリンクなど一部のHTMLは表示したい場合、すべてをエスケープするわけにはいきません。このようなケースこそ、本来の意味での「サニタイズ（危険な要素だけを取り除く処理）」が必要になります。

DOMPurify：JavaScriptで広く使われているHTMLサニタイズライブラリ。<script> や onerror などのイベント属性を取り除いたHTMLを返します。
WordPressの wp_kses() / wp_kses_post()：許可したタグ・属性だけを残す関数です。
ブラウザ標準のHTML Sanitizer API（setHTML()）：innerHTML の代わりに使うと、危険な要素を取り除いてからHTMLを挿入できる新しい仕組みです。2026年2月公開のFirefox 148が先行して搭載しましたが、2026年10月時点ではまだ全ブラウザで使える状態ではありません。対応しているかを確認し、未対応ならDOMPurifyなどに切り替える実装が必要です。

正規表現で <script> を消すような自作のサニタイズは、大文字・小文字の混在や属性を使った回避（<img src=x onerror=...> など）に弱く、おすすめできません。

よくある実装ミス

エスケープを入れ忘れる箇所がある：確認画面・エラーメッセージ・管理画面など、「メイン画面以外」の出力で漏れやすくなります。
属性値をクォートで囲んでいない：value=<?php echo $v; ?> のようにクォートがないと、スペース1つで新しい属性を追加されてしまいます。
文字コードを指定していない：HTMLやエスケープ関数で文字コード（UTF-8）を明示しないと、文字コードの解釈の違いを突いた攻撃を受けるおそれがあります。
自動エスケープを無効にする機能を気軽に使う：raw、|safe、dangerouslySetInnerHTML などを使う箇所は、入力元を必ず確認しましょう。
ブラウザ側のチェックだけで満足する：前述のとおり、サーバ側でも同じ検証が必要です。

Cookieのセキュリティ対策

Cookieを介したXSSやセッションハイジャックを防ぐためには、サニタイズだけでなくCookieの設定そのものに対しても配慮が必要です。たとえば、

HttpOnly属性
- JavaScriptからCookieへアクセスできなくなるため、XSSによるCookieの盗難リスクが下がります。セッションIDを入れるCookieには必ず付けましょう。
Secure属性
- HTTPS通信時のみCookieを送受信するようになります。平文通信でCookieが盗聴されるリスクを減らします。HTTPSの仕組みは「HTTP/HTTPSとは？ステータスコード・ヘッダー・TLSの仕組み」で解説しています。
SameSite属性
- クロスサイトリクエスト（CSRFなど）を防止するための属性です。Lax や Strict に設定することで、安全性を高められます。
  - SameSite=Lax → 通常のナビゲーション時のリクエストにはCookieが送信されるが、クロスサイトのフォーム送信時などでは送信されない（推奨）。
  - SameSite=Strict → 完全にクロスサイトのリクエストではCookieを送信しない（ただし、ユーザビリティが低下するため慎重に適用）。
  - SameSite=None → クロスサイトでもCookieを送信する。外部サイトへの埋め込みなどで必要な場合に限って使い、Secure 属性とセットで指定する必要があります。
- Chrome・EdgeはSameSite属性が指定されていないCookieを Lax として扱いますが、ブラウザによって扱いが異なるため、既定の動作に頼らず明示的に指定するのが確実です。また、SameSiteはCSRF対策の補助であり、重要な処理ではCSRFトークンなどの対策も併用しましょう。
Cookie名の接頭辞（__Host-）
- Cookie名を __Host- で始めると、「Secure属性あり・Domain属性なし・Path=/」の条件を満たさない限りブラウザがCookieを受け付けません。サブドメインなどからセッションCookieを上書きされる攻撃を防げます。
エスケープ・バリデーション
- Cookieの値をHTMLなどに出力する場合は、適切にエスケープまたはサニタイズすることを忘れないようにしましょう。

これらをまとめて設定すると、セッションCookieは次のようになります。

Set-Cookie: __Host-session=xxxxxxxx; Path=/; Secure; HttpOnly; SameSite=Lax

レバテックキャリアの評判は？ITエンジニア転職のメリット・注意点【2026年】

サニタイズだけでは不十分：総合的な対策が必要

サニタイズは非常に重要な工程ですが、それだけで全ての攻撃を防げるわけではありません。
バリデーションによる危険なデータの排除や、プリペアドステートメント（Prepared Statement）によるSQLインジェクションの防止、CookieへのHttpOnly属性付与、サーバ側の権限設定や構成管理など、複数の手法を組み合わせることで、初めて堅牢なセキュリティが実現します。

アプリケーションのコード以外にも、次のような「多層防御」を組み合わせると、1つの対策が漏れても被害を食い止めやすくなります。

対策	役割
Content Security Policy（CSP）	HTTPレスポンスヘッダーで、実行を許可するスクリプトの読み込み元を指定する。XSSが起きてもスクリプトの実行を防ぎやすくなる
フレームワーク・ライブラリの更新	WordPress本体やプラグイン、利用ライブラリの既知の脆弱性をふさぐ
WAF（Webアプリケーションファイアウォール）	典型的な攻撃パターンを通信の段階でブロックする。ただしアプリ側の対策の代わりにはならない
最小権限の原則	DBユーザーやサーバのアカウントに必要な権限だけを与え、侵入されたときの被害を限定する
脆弱性診断・コードレビュー	リリース前や大きな改修のあとに、第三者の目やツールで抜け漏れを確認する

体系的に学びたい場合は、IPAが無料で公開している「安全なウェブサイトの作り方」（改訂第7版）が参考になります。XSSやSQLインジェクションなど代表的な脆弱性ごとに、根本的な解決策と保険的な対策が整理されています。ただし2015年公開の資料なので、Cookie属性やブラウザの新機能など変化の速い部分は、最新の公式ドキュメントもあわせて確認してください。

DNSキャッシュポイズニングとは？攻撃の仕組みから具体的対策まで徹底解説

サニタイズに関するよくある質問

Q. サニタイズは入力時と出力時、どちらで行うべきですか？

A. 入力時には「バリデーション（形式チェック）」、出力時には「出力先に合わせたエスケープ」を行うのが基本です。データは元の形で保存し、表示や利用のたびに出力先に合わせて処理することで、データを壊さずに安全性を保てます。HTMLの一部を許可する場合のサニタイズは、保存前と表示前のどちらで行うかを決め、処理が漏れないように一か所にまとめましょう。

Q. フレームワークを使っていればサニタイズは不要ですか？

A. 自動エスケープやORMのおかげで多くの攻撃は防げますが、不要にはなりません。自動エスケープを無効にする書き方（raw や dangerouslySetInnerHTML など）、生のSQLを書く処理、URLを属性に入れる処理、ファイルアップロードなどは、フレームワークの保護が届かない部分です。

Q. サニタイズとクレンジングは同じ意味ですか？

A. 似ていますが目的が異なります。データクレンジングは、表記ゆれや重複、誤入力を整えて「データの品質」を高める処理です。一方、サニタイズは「セキュリティ上の危険」を取り除く処理を指します。

Q. 「サニタイズ」はセキュリティ以外の意味でも使われますか？

A. はい。データ消去の分野では、廃棄するパソコンや記憶媒体のデータを復元できないように消去することを「データサニタイズ（メディアサニタイズ）」と呼びます。また、日常会話では「消毒する」という本来の意味で使われることもあります。本記事で扱っているのは、Webアプリケーションにおけるデータの無害化の意味です。

まとめ

サニタイズ（sanitize）は「不正データを無害化する」重要な手段ですが、バリデーション（危険なデータの受け取り拒否）やプリペアドステートメント（Prepared Statement）の利用など、より根本的な対策と併せて実施することが不可欠です。
エスケープ（escape）は、サニタイズとは厳密に異なる概念で、利用するコンテキストごとに特殊文字を適切に変換します。入力時にまとめて処理するのではなく、出力の直前に出力先に合わせて行うのが基本です。
HTMLの一部を許可したい場合は、自作の置換処理ではなく、DOMPurifyや wp_kses() などの実績あるサニタイザーを使いましょう。
ファイルアップロードやCookieの取り扱いなどでは、サニタイズだけでなく、実行権限の制限やCookieのSecure/HttpOnly/SameSite属性の設定など、複数の角度からセキュリティを向上させる必要があります。
最終的には、CSPやライブラリの更新なども含めて複数のセキュリティ対策を総合的に組み合わせることで、Webアプリケーションやシステム全体の安全性が大幅に高まります。