サーバとクライアント両方でバリデーションを行う理由

サーバ側でバリデーションを行う理由

主な目的はセキュリティとデータ整合性の確保

クライアント側のバリデーションは信用できない

• クライアントのコードは、ユーザーが意図的に改変可能
  • ブラウザ開発者ツールでJavaScriptを無効にしたり、検証処理をバイパスしたりできる
• 悪意あるリクエスト（不正なデータ送信、攻撃）が行われる

サーバは最終防衛ライン

• 不正なリクエストや想定外のデータを必ず検出して拒否しなければならない
• サーバに間違ったデータが入ると、後続処理でエラーや障害が発生する可能性がある

データベースへの不正データ混入を防止する

• SQLインジェクション、型不一致、文字コードエラーなどへの対策にもなる

クライアント側でバリデーションを行う理由

主な目的はユーザビリティの向上

即時フィードバックを提供できる

• 「この項目は必須です」「メールアドレスの形式が正しくありません」とリアルタイムで通知できる
• ユーザーが無駄なフォーム送信をする前にエラーを知ることができる

サーバへのリクエスト回数を減らせる

• 形式エラーなどをクライアントで弾けば無駄なネットワーク通信を防げる
• サーバの負荷を軽減できる

スムーズな体験を作れる

• 画面遷移なしでエラー修正が可能
• レスポンス待ちによるストレスがない

具体的なバリデーション例

例えば、ユーザー登録フォームの場合

クライアント側チェック

• 入力必須チェック
• メールアドレス形式チェック
• パスワード長さチェック（例：8文字以上）
• リアルタイムで「ここを直してください」メッセージを出す

サーバ側チェック

• 同様にすべての入力値の正当性検証
• メールアドレスの一意性チェック（すでに登録されていないか）
• 不正リクエスト（例：意図しないフィールド追加）を無視または拒否
• レートリミットやCSRFトークン検証など、より強固な安全対策