入力バリデーション

なぜ学ぶか： 「ユーザーは正しい値を入れてくれる」— この善意の前提が、セキュリティの穴の入口です。特にAIは正常系を上手に書く反面、「悪意ある入力」「フロントの検証は迂回できる」という発想が抜けがち。『入力を信じない』は、あらゆる防御の土台です。

外から来た入力は疑う

フォーム・URLパラメータ・APIの受信データはすべて「加工されているかもしれない」と考えます。

フロントの検証は「親切」、サーバーの検証は「防御」

ブラウザ側のチェックは迂回できます（開発者ツールで直接送れる）。本当の防御はサーバー側の検証です。両方必要で、役割が違います。

サーバーではzodで検証

前のフェーズで学んだzodが、ここで武器になります。Route HandlerやServer Actionの入口で、形・長さ・範囲を検証してから処理します。

AIコードの定番の穴

「フロントでmaxLengthを付けて満足」「サーバーは入力を無検証で保存」。この組み合わせを見たら指摘します。

コード例

// app/api/comment/route.ts — サーバー側の検証（本当の防御）
import { z } from "zod";

const CommentSchema = z.object({
  content: z.string().min(1).max(500), // 長さを必ず制限
});

export async function POST(request: Request) {
  const parsed = CommentSchema.safeParse(await request.json());

  // フロントで何をされても、ここで弾く
  if (!parsed.success) {
    return Response.json({ error: "入力が不正です" }, { status: 400 });
  }

  // ここに来た時点で content は検証済み
  return Response.json({ ok: true });
}

フロントの検証はユーザー体験のため（すぐ赤字で教える）、サーバーの検証は防御のため。攻撃者はフロントを飛ばして直接サーバーを叩けるので、サーバー検証が本丸です。

ステップ 1 / 2

← カリキュラム一覧へ戻る

※ カリキュラムの内容はAIが生成しており、誤りが含まれる場合があります。正確な情報は公式ドキュメント等でご確認ください。