フォームとバリデーション

バリデーションとは

バリデーション（検証）とは、ユーザーが入力した値が正しい形式・範囲に収まっているかを確かめる仕組みです。たとえば次のようなチェックを指します。

• 必須：名前やメールアドレスが空欄でないか。
• 形式：メールアドレスが xxx@yyy.zzz の形か、電話番号が数字か。
• 範囲・長さ：パスワードが 8 文字以上か、年齢が 0 以上 150 以下か。
• 一致：「パスワード」と「パスワード（確認）」が同じか。

なぜ必要かというと、不正な値をそのまま受け取ると、後続の処理が壊れるからです。空の名前、桁の足りない電話番号、文字が入った金額——こうしたデータが DB に入ると、表示が崩れたり計算が狂ったり、最悪セキュリティ事故につながります。入口で弾くのがバリデーションの役割です。

検証はどこで行うのか

バリデーションを行う場所は大きく 2 か所あります。どちらか一方ではなく、両方で行うのが基本です。

検証の場所	実行されるタイミング	主な狙い
クライアント側	ブラウザ上（送信前）	即座に教えて親切にする（UX）
サーバ側	サーバに届いた後	不正なデータを確実に弾く（安全）

それぞれ目的が違います。クライアント側は「ユーザーに早く・優しく教える」ため、サーバ側は「何があっても不正を通さない」ため。役割が異なるので、両方そろって初めて意味を持ちます。

クライアント側：速くて親切

クライアント側のバリデーションは、サーバへ送る前にブラウザ上でチェックします。入力した瞬間や送信ボタンを押した瞬間に「メールアドレスの形式が正しくありません」と教えられるため、待ち時間がなく親切です。

HTML の標準属性だけでも、基本的な検証は書けます。

<form>
  <!-- required: 必須 / type=email: メール形式 / minlength: 最小文字数 -->
  <input type="email" name="email" required />
  <input type="password" name="password" required minlength="8" />
  <input type="number" name="age" min="0" max="150" />
  <button type="submit">登録</button>
</form>

より細かい条件は JavaScript で補います。

form.addEventListener("submit", (e) => {
  if (password.value !== confirm.value) {
    e.preventDefault(); // 送信を止める
    alert("パスワードが一致しません");
  }
});

サーバ側：堅くて最後の砦

サーバ側のバリデーションは、データがサーバに届いてから改めてチェックします。クライアント側と同じ内容でも、もう一度検証します。一見二度手間ですが、これがセキュリティ上の本丸です。

// サーバ側：届いた値を必ず検証してから処理する
app.post("/register", (req, res) => {
  const { email, password } = req.body;
  if (!email || !email.includes("@")) {
    return res.status(400).send("メールアドレスが不正です");
  }
  if (!password || password.length < 8) {
    return res.status(400).send("パスワードは 8 文字以上にしてください");
  }
  // ここまで通って初めて保存処理へ
});

クライアント側を通過した値であっても、サーバは「信用できない入力」として扱い、ゼロから検証し直すのが鉄則です。

なぜ両方とも必要か

「クライアント側で弾いているなら、サーバ側は要らないのでは？」と思いがちですが、これは危険な誤解です。理由は クライアント側の検証は簡単に回避できるから。

• ブラウザの開発者ツールで required 属性を消す。
• ブラウザを通さず、curl などで直接サーバへリクエストを送る。
• JavaScript を無効にして送信する。

つまりクライアント側の検証は親切なガイドであって、防御壁ではありません。攻撃者はブラウザの制約を無視できるため、サーバ側で検証していなければ、不正なデータがそのまま入り込みます。

まとめ

• バリデーション：入力値が正しい形式・範囲かを検証し、不正な値を入口で弾く仕組み。
• クライアント側：ブラウザ上で即座にチェック。速くて親切（UX 担当）。だが回避できる。
• サーバ側：届いた後に必ず再検証。堅くて確実（安全担当）。これが最後の砦。
• 結論：両方必要。クライアント側は信頼せず、サーバ側で必ず検証する。

入力を受け取るサーバ側の通信は HTTP、ログイン状態の扱いは Cookie とセッション と関わります。攻撃の前提知識は Web 認証 も合わせて押さえると、なぜ二重チェックが要るかが腑に落ちます。