入力欄の検査を頼むとき、画面側だけでは足りないと知った

• 画面側の検査は、親切のためであって防御ではない
• 受け取る側でも、必ず同じ検査をする
• 頼むときは「両方で」と明示する

問い合わせの入力欄に、形式の検査を入れた。画面側だけで満足していたが、それでは足りないと指摘を受けた。

画面側の検査でできること

ブラウザ上で止める検査には、役割がある。

• 間違いをその場で知らせる
• 送信してからエラーになるのを防ぐ
• 入力する人の手間を減らす

どれも使う人のための機能だ。安全のための仕組みではない。

なぜ足りないか

画面側の検査は、迂回できる。

• ブラウザの機能で、検査を無効にできる
• 画面を使わず、直接データを送れる
• 送られた側は、どう送られたか区別できない

3つ目が要点だ。受け取る側から見れば、画面を経由したかどうか分からない。

両方でやる

いまは、必ず両方に入れている。

• 画面側 — 入力中に知らせる。使いやすさのため
• 受け取る側 — 保存や送信の前に検査する。安全のため
• 検査の内容は、同じにする

3つ目を揃えないと、画面では通るのに受け取る側で弾かれるという状態になる。

頼み方

こう書くようにした。

入力欄の検査を入れてください。

- 画面側（ブラウザ）と、受け取る側の両方
- 検査の内容は同じにする
- 受け取る側では、画面側を経由していない
  送信も想定する

それぞれ何をしているか、説明を付けてください。

3つ目を書くのが重要だ。明示しないと、画面側だけで済まされることがある。

検査する項目

最低限、この4つは見ている。

• 空でないか
• 長さが妥当か。極端に長い入力を弾く
• 形式が合っているか。メールアドレスなど
• 想定していない文字が含まれていないか

2つ目を忘れやすい。長さの上限が無いと、巨大なデータを送られることがある。

出力するときも検査する

入力を受け取るときだけでなく、出すときにも処理が要る。

• 受け取った内容を、そのまま画面に出さない
• 記号を、そのまま表示される形に変換する
• 保存する前と、表示する前の両方で考える

1つ目は何度も言われることだ。入力をそのまま出すと、画面の作りが壊されることがある。

送信された後の扱い

検査を通った後にも、気をつける点がある。

• 受け取った内容を保存する場所
• 管理画面で表示するときの処理
• メールで転送するときの処理

2つ目を見落としていた。送信された内容を自分が管理画面で見るとき、そこでも同じ問題が起きうる。外から見える場所だけでなく、自分しか見ない画面でも処理が要る。既存の仕組みを使えばここも含めて作られているが、自分で作ると、見落としやすい部分だった。

自分で確かめる

コードが読めなくても、試せば分かる。

• 空のまま送信してみる
• 長い文字列を入れてみる
• 記号を入れて、画面が崩れないか見る
• 形式の違うメールアドレスを入れてみる

どれも実際に触れば分かる。読む代わりに、試すという形で確認できる。

画面側を無効にして試す

さらに踏み込んだ確認もできる。

• 開発者ツールで、入力欄の制限を外す
• その状態で送信する
• 受け取る側で弾かれるか確認する

弾かれなければ、受け取る側に検査が入っていない。

エラーの見せ方

弾いたときに、何が悪いか伝える必要がある。

• どの項目が、なぜ駄目かを示す
• 入力した内容は消さない。やり直しが面倒になる
• 技術的な文言を出さない。利用者には分からない

2つ目を失敗した。エラーで戻ったときに全部空になり、長い文章を書き直させてしまった。入力を保持しないと、送信をやめる人が出る。3つ目も重要で、内部の処理に関する文言がそのまま出ていると、作りの情報が漏れる。利用者向けの言葉に置き換えるよう、明示して頼んでいる。

既存の仕組みを使う

最終的には、自分で作らない判断をした。

• 問い合わせの仕組みは、既にあるものを使う
• 検査も含めて、作られている
• 問題が見つかれば、更新で直される

3つ目が大きい。自分で作ると、問題が見つかっても誰も教えてくれない。

まとめ

• 画面側の検査は、使いやすさのためであって防御ではない
• 受け取る側でも、同じ検査を必ず入れる
• 頼むときは「両方で」と明示する
• 長さの上限を忘れない
• 画面側の制限を外して送信し、弾かれるか確認する