ラボ > PHP:HTML、Javascript絡み、セキュリティ関連、FuelPHP:validation、Javascript関連:form、HTML:form関連

Form送信のバリデーションの流れのメモ

Form送信時の値チェックについての諸々・・・メモ

作成日:2022-02-08, 更新日:2022-02-08

基本的な考え方

絶対じゃない。あくまで私の考え方なので参考までに

  • 面倒なコトはしたくない
    • PHPで処理実行する前に最終チェックをしないと怖い
    • PHPで最終チェックをするんだからJavascriptで細かくチェックはしない

セキュリティ対策も考慮する

  • 余計な値は拒否。受け取っても早いタイミングで処理を止める
  • 受け取りたい値はエンコード・デコードを適切に行う
  • 出力する値もエンコード・デコードを適切に行う

Form入力画面~処理実行までの流れ

  1. 入力画面
    • 送信ボタン押下前の入力チェックは基本しない
    • 送信ボタン押下でAPI経由でバリデーションチェック
      • バリデーションエラーがあったらそのままエラー出力(javascript処理)
      • バリデーションエラーが無ければそのままForm送信(javascript処理)
  2. 確認画面
    • ひとまずバリデーションチェック
      Form送信時にバリデーションチェック済みなので、ココでのエラーは不正扱い→403エラー
    • 送信ボタン押下でForm送信
  3. 処理実行(※DBに保存とか)
    • ひとまずバリデーションチェック
      Form送信時にバリデーションチェック済みなので、ココでのエラーは不正扱い→403エラー
    • DBに保存とか各処理を行う
    • サンキューページや任意のページを表示して完了

※CSRFが都度、書き換わるならその対応も必要

バリデーションの流れ

  1. 403エラーにする
    1. 必要なものが無ければ弾く
    2. 想定外の値は弾く1
  2. バリデーションエラーにする
    1. 想定外の値は弾く2
    2. 書式エラーとかはバリデーションエラー
    3. 値が妥当じゃないなら、バリデーションエラー

必要なものが無ければ弾く

例えば「input[name=hoge」をformにセットしているのに「$_GET['hoge']」とかが存在しないとき。
→ブラウザでアクセスしていない可能性がある
→余計なコトするな・・・ってことで「403エラー」

想定外の値は弾く1

selectタグやラジオボタン、チェックボックス、「input[type=hidden]」のように使われる値が決まっているのに想定外の値が入ってきている
→勝手に書き換えたか変なコトをしている可能性がある
→余計なコトするな・・・ってことで「403エラー」

極端な文字数

具体的な数字は出せないし、即403エラーと判断するのも微妙ではある

  • 日本の郵便番号入力欄
    10文字ぐらいまでなら入力ミスかなと思うけど、100文字とかなると変なコトしていると思う
  • 姓名の入力欄
    日本人で姓名あわせて50文字の人っているのかな・・・
    ※ちなみに「じゅげむ」が100文字超えで、外国にはファーストネームとミドルネーム、ラストネームを合わせて700文字を超える人がいるとか・・・

想定外の値は弾く2

Javascriptで制御している部分の想定外のエラー・・・バグの可能性もあるので「403エラー」にするか「バリデーションエラー」にするかは悩む
※「通常に入力するとエラー制御で止まるけど、コピペしたら通る」・・・みたいなヤツ。

  • 例えば100文字まで入力できないようにしているのにそれ以上の文字数が来たとき
  • 例えばカレンダークリックで「年月日」が自動入力されるのに「年月日」の書式じゃない

→運用次第で「403エラー」or「バリデーションエラー」にする

書式エラーとかはバリデーションエラー

例えば、「数字だけ」「全角文字はNG」「メアドの書式じゃない」・・・などは通常のバリデーションエラー

値が妥当じゃないなら、バリデーションエラー

例えば、「都道府県から住所を入力してね」と言っているのに「都道府県」が入っていない、日付の入力欄に「2022-02-30」のような存在しない日にちが入っている・・・などは通常のバリデーションエラー

バリデーションと空白削除や文字の変換対応

「入力内容の最初と最後の空白」や「カナ指定で平仮名入力」や「半角数字指定で全角数字入力」はどうするのかって問題がある。
もちろん、バリデーションエラー扱いでもOK。
ユーザービリティを考えるとプログラム側で対応してあげた方が良い
対応してあげる場合は403エラーのチェック対応後が無難かな?

関連項目