- ユーザーやシステムが入力したデータが期待する形式・範囲・内容に合致しているかを検証（確認）する処理・仕組みのこと
- メールアドレスの形式チェック・年齢が0〜150の範囲内か・必須項目が入力されているかなど不正なデータがシステムに入り込む前に検出・拒否する防御線の役割を担う
- フロントエンド（ブラウザ）でのバリデーションはUXのため・サーバーサイドでのバリデーションはセキュリティのためで、両方を必ず実装することが原則だ
【深掘り】これだけ知ってればOK！
バリデーションの種類を整理しよう。形式チェック：メールアドレスのフォーマット（@が含まれているか）・電話番号が数字のみか・日付が有効な形式かなど。範囲チェック：年齢が0〜150の整数か・価格がマイナスでないか・文字数が制限内かなど。必須チェック：必須フィールドが空でないか。一意性チェック：ユーザー名やメールアドレスが既に使われていないか（DBとの照合）。業務ルールチェック：開始日が終了日より前であるかなど業務固有のルールの検証。
フロントエンドとサーバーサイドの両方でバリデーションが必要な理由を理解しよう。フロントエンドバリデーションはユーザーが入力した直後にリアルタイムでフィードバックを返すことで使いやすさを高める。ただしフロントエンドのバリデーションはブラウザの開発者ツールで簡単に無効化できるため、セキュリティ対策にはならない。サーバーサイドバリデーションはデータベースへの保存前に必ず実行する最後の防衛ラインで、クライアントから何が送られてきても必ず検証する。
バリデーションのエラーメッセージ設計もUXの重要な要素だ。「入力エラーが発生しました」という曖昧なメッセージよりも「メールアドレスの形式が正しくありません（例: name@example.com）」のように何が間違っていてどう直せばいいかを具体的に示すことで、ユーザーの操作ミスを減らしコンバージョン率の向上につながる。フォームのどのフィールドでエラーが発生したかをフィールドの近くに表示することが重要だ。
よくある誤解
フロントエンドでバリデーションしているからサーバーサイドは不要だと思っている
フロントエンドのバリデーションはブラウザの開発者ツールやcurlコマンドで簡単に無効化できる。攻撃者は直接APIにリクエストを送ることができるため、サーバーサイドのバリデーションなしでは不正なデータが入り放題になる。フロントエンドはUX用・サーバーサイドはセキュリティ用という位置付けで両方が必須だ。
バリデーションをすれば全ての不正入力を防げると思っている
バリデーションは形式・範囲・必須の検証には有効だが、SQLインジェクション・XSSへの完全な対策にはエスケープ処理・プリペアドステートメントの組み合わせが必要だ。バリデーションは多層防御の第一層であり、それだけに頼らず各種のセキュリティ対策を組み合わせることが重要だ。
会話での使われ方
このAPIエンドポイント、サーバーサイドのバリデーションがありません。フロントでチェックしているからといって省略しないでください。直接curlで叩けば何でも入ります。
シニアエンジニアがAPIのバリデーション実装漏れをコードレビューで指摘している場面。
フォームのエラーメッセージが全部「入力エラー」だけで何が間違っているか分からないですね。各フィールドに具体的なガイダンスを追加してコンバージョン率を改善しましょう。
UXデザイナーがフォームのエラーメッセージのわかりにくさを改善提案している場面。
年齢フィールドに-1や9999を入れてもエラーにならないバグがありました。0〜120の範囲バリデーションを追加してください。
テスターがバリデーション漏れを発見して開発者に修正を依頼している場面。
【まとめ】3つのポイント
- 入力値が正しい形式・範囲・内容かを検証してシステムに入り込む前に防ぐ：不正な値のDB書き込み・SQLインジェクション・XSSの多くはバリデーション不足が原因であり、形式・範囲・必須・業務ルールの4種類のチェックをシステム入口で徹底することが品質とセキュリティの基盤だ
- フロントエンドはUX用・サーバーサイドはセキュリティ用で両方必須：フロントエンドのバリデーションはブラウザで無効化できるためセキュリティ対策にならず、サーバーサイドでの二重チェックがどんな入力が来ても必ず実行される最後の防衛線だ
- バリデーションとエスケープ処理の組み合わせがWebセキュリティの基本：バリデーションだけではSQLインジェクション・XSSへの完全対策にならないため、プリペアドステートメントやHTMLエスケープとの組み合わせで多層防御を構築することが重要だ
よくある質問
-
Qフロントエンドバリデーションとサーバーサイドバリデーションはどちらを先に実装すべきですか？
-
A
どちらを先にするというより、両方とも必ず実装する必要があります。開発の順序としてはAPIを先に作ってサーバーサイドのバリデーションを実装し、その後フロントエンドにUX向けのバリデーションを追加する流れが多いです。
-
QReactでのフォームバリデーションはどのライブラリが使いやすいですか？
-
A
React Hook FormとZodの組み合わせが現在最も人気のある選択肢です。React Hook FormはパフォーマンスのよいフォームライブラリでZodはTypeScriptと相性のよいスキーマ定義・バリデーションライブラリです。FormikもPopularな選択肢で、シンプルなフォームならHTML5のbuilt-inバリデーションも使えます。
-
QSQLインジェクションとバリデーションはどう違いますか？
-
A
バリデーションは入力値が正しい形式・範囲かを検証する処理です。SQLインジェクション対策はバリデーションに加えてプリペアドステートメント（パラメータ化クエリ）を使うことで、SQLに悪意のある文字列が混入しても無害化します。バリデーションだけではSQLインジェクションを完全には防げません。
-
Qバリデーションエラーはどのタイミングで表示するのがベストですか？
-
A
入力フィールドからフォーカスが外れた時（onBlur）に表示するのが最も一般的です。リアルタイム（onKeyUp）での表示は入力中にエラーが出て使いにくいことがあります。フォーム送信ボタンを押した後に全エラーをまとめて表示する方法もありますが、フィールド数が多いと使いにくいです。
この用語と一緒に知っておきたい用語
| 用語 | この記事との関連 |
|---|---|
| サーバー | サーバーを押さえると本記事の理解がさらに深まります。ネットワークを通じて情報やサービスを提供する側のコンピューターのこと。レストランで料理を運んでくれる給仕係（server）をイメージするとわかりやすいよ |
| SQLインジェクション | SQLインジェクションは関連分野でよく登場する重要キーワードです。Webアプリのフォームに不正なSQL文を入力し、DBへの不正アクセスやデータ窃取・改ざん・削除を引き起こす古典的ながら現在も多発する攻撃だ |
| データ | 本記事のテーマと実務上セットで使われることが多い用語です。コンピュータが処理する数値や文字、画像といった事実や資料そのもの、それがデータだ |
| プリペアドステートメント | プリペアドステートメントは関連分野でよく登場する重要キーワードです。データベースへの命令文（SQL）を、穴埋め式の「ひな形（テンプレート）」として先に準備しておく仕組みのことだよ。 |
| エスケープ処理 | エスケープ処理を押さえると本記事の理解がさらに深まります。エスケープ処理の主要な特徴と用途を理解することで、関連する技術・制度・概念を正確に把握できるようになる |
【出典】参考URL
https://cheatsheetseries.owasp.org/cheatsheets/Input_Validation_Cheat_Sheet.html ：OWASPインプットバリデーションチートシート
https://developer.mozilla.org/ja/docs/Learn/Forms/Form_validation ：MDNのフォームバリデーションガイド
https://zod.dev ：TypeScriptでのバリデーションライブラリZodの公式サイト
コメント