フロント側で入力チェックをしていればサーバー側では入力チェックは必要ない？

Question

どういうタグをつければいいのかわからないので、タグは適当です^^;
今一緒に仕事をしている人（仮にAさんとします）とコーディングというか実装というか、その辺りで考え方が違いすぎて全く噛み合わないので、
どちらが正しいのか識者の方に意見を伺いたいと思います。

WEBアプリケーションの開発をしています。
Aさんが作った部分を私がテストしたらサーバーサイドで入力値の長さをチェックしていませんでした。
それを指摘したことろ、Aさんは「何言ってんだコイツ」みたいな感じで「inputにmaxlength付けてるのになんでそんな無駄なことしなきゃいけないんだ」と反論されてしまいました。
私はmaxlengthなんてブラウザの開発者ツールで変更できるし、サーバーサイドでも長さチェックすべきと言い返しましたが
鼻で笑われました。
Aさんが作った既存のシステムでinput要素のmaxlegthを変更して長いデータを送ったところエラー画面に遷移しました。
たぶんinsert文でコケたんだと思いますが、Aさんは「そんなことする奴は滅多にいないし、仮にいたとして何か問題でも？データが消えたり壊れたりするわけでもないし。」と言っていました。
自分の取り越し苦労が過ぎるのか、Aさんがルーズ過ぎるのか、どっちでしょうか？

Answer 1

フロントエンド側のJavaScriptを動かすための入力の場合は別ですが、そうでない場合（バックエンドにそのまま流す値）のフロントエンドバリデーションは、入力補助のためにあると考えてください。

DBレベルで不正入力を弾けるのならそれでいいのですが（関連質問）、万が一にも不整合なデータが入ってしまうと、あとあと苦労することになります。

Answer 2

事業のフェーズや性質によると思います。

例えばスタートアップのプロダクトで、とにかくスピード感とプロダクトマーケットフィットの検証を！というはなしであれば、Aさんの論調はケースバイケースで正しいです。スピードをとります。（ただし、これは後のフェーズでやりもれがないようにちゃんとタスクとして残しておき、管理する）
ケースバイケースといったのは、セキュリティ関連はたとえ上記のようなパターンでもNGです。

反対に、例えば受託の納品する成果物としてなら、不良品レベルですね。クライアント会社側で気づきづらいだけ悪質とも言えます。プロしか気づけない欠陥なんだがらそこはプロとして品質保証すべきでしょう。悪質な受託会社として名を馳せたいのなら正解ですが。

Comments

[intron]

スタートアップではないです。社内システムでもありません。

> 反対に、例えば受託の納品する成果物としてなら、不良品レベルですね。

私もそう思うのですが、Aさんは「何か問題でも？」って感じなので、会社で喋ってると胃のあたりがムカムカしてきます。つらい;;

[h_daido]

ここで喋って発散しましょうw
その方は、一刻も早く帰りたい腰掛けのパートのおばちゃんと同じレベルのプロ意識です。
プロ意識を期待すること自体が無謀なので、さらに上の上司と品質保証できるスキームを作っちゃったほうが建設的だと思います。
まだ、そういうことが難しい役職なのであれば、今は藁人形に五寸釘を打ち込んで、はやく偉くなるしかないですね。

[intron]

大分ストレス発散できましたww
自分は非正規雇用で偉くはなれないので、今担当している部分は粛々と開発して、なるべく早くこの現場から逃げれるようにしたいと思います。
ありがとうございます。

[intron]

他の回答者の皆様もありがとうございました。
「サーバーサイドでもチェックすべき」と「サーバーサイドでのチェックは必須」という意見ばかりで心強く思いました。
今回相談した件以外にもAさんは技術面で首を傾げたくなるようなことを色々言っているので、今度何か変なことを言ってきたら強く反論したいと思います。

Answer 3

システムの仕様書やテスト仕様書が
どのレベルまでのチェックを必要としているかに依存するかも。
そこを決めずに書いていてコーディングの品質がばらつくのは問題あり。

個人的には、サーバー側でしっかりバリデーション処理を書きます。
面倒でも、事前にわかっている、不都合な文字(列)を含んでいたら排除するように。
テスト仕様書にも異常文字列のテスト項目を載せたことがありますし。

Comments

[intron]

バリデーションのことを書いた仕様書がありません。HTMLとテーブルの仕様はあります。AさんはSE兼PGなので仕様書作るとしたらAさんですが、今のところ作っていないようです。非常に短納期なので実装が終わってから作るつもりなのかもしれません。

[退会済みユーザー]

コストに見合わないと判断してノータッチを決め込んでいるのかもしれません。
短納期の仕事にはありがちな話です。
異常な文字列を受信して処理したときに、intronさんに火の粉が降ってこないよう、
「こういう問題点を指摘した、しかしAさんがこう判断しているので対策を打てなかった」などの
エビデンスを残すことも大事かもしれません。

Answer 4

サーバー側チェックは必須です。
むしろ省略できるのはクライアントチェックでしょう。

データが壊れないといっていますが、以前わたしがテストしていたシステム(本番ではない)で性別に想定していない値を送ったら壊れて、復旧されるまで画面が表示されないという事態に陥ったことがあります。

insert文でコケ

ればまだいいですが、そうでない場合、maxlength以下の文字列しか来ないと思っているそれを使っていることろすべてに影響してしまいます。

Answer 5

社内で使われるのが前提で、

そんなことする奴は滅多にいない

のなら、まぁいいかなとは思います。（私は気持ち悪いので、普通にチェックするべきだと思いますが）

データが消えたり壊れたりする

この可能性があるなら、サーバサイドでのチェックは必須です。

そもそもで、MVCモデルでいうとMの部分が長さチェックをするわけで、ブラウザの機能なんて関係ないですし、
今は知らないけど、maxlengthが文字数なのか、バイト数なのか昔はブラウザの実装が違うので
そもそも使えなかったですね。

Comments

[intron]

社内で使うシステムではないです。お客様からお金もらって作っているシステムです。

Answer 6

ユーザーから送られてくるデータは全て汚染されていることを原則としていないのですね
汎用性という意味では低レベルのプログラミングですし、
仕様書とか起こしたことがないのでしょうか
すくなくともAさんに受託業務は任せられません

とはいえ郷にいればなんとやら・・・Aさんがルールブックならそれ以上のことをいうと
角が立つばかりなのでもはや何も言うべきではないです
ご自身が担当した箇所については粛々ときちんとしたコーディングをされたほうが
良いでしょう。

Answer 7

基本的に仕様書がどうなっていようがサーバーでの入力チェックは必須です。

フロント側での入力チェックはユーザーの利便性のためです（入力の不備を早い段階で教えるため）、フロント側で入力チェックするからOKなどという仕様書は見たことがありませんし、記載していないのならば確認すべき基本的な事項です。
どんなシステムであれサーバー側の入力チェックなしにDBに突っ込むことなど有りえません、というかSQLインジェクションとか大丈夫なのか心配になってきます。

Answer 8

すでに解決済みですがコメントさせていただきます。

私は基本的考えとして「ＤＢに格納するものはサーバサイドのチェックを必須にすべき」と思います。

ＡさんはＡさんなりの意図があってのことだとは思いますが、
Ａさんの品質はそのまま会社の品質になります。
intronさんの品質もそのまま会社の品質になります。

「私たちがお客様に提供する製品の品質としてどうあるべきか」を考えるべきで、誰かの意見だけで品質決定してしまわないことが重要だと思います。

納期や費用の問題もありますから、すべてのシステムを完璧にとはいかないのが現実です。
そういう場合にどこにリソースを費やしどこのリスクは許容するのかといったことは、会社の決定または品質管理に責任ある者の決定に従うことだと思います。

あとは、後々「なんでこうなってるの？」という疑問が出ることは間違いないでしょうから、ドキュメントでも検査項目書へのコメントでもノートのメモ書きでもとにかく何でもよいので痕跡を残すことです。
それが後で自信の身を助けてくれるはず。（実体験）

がんばってください。

Answer 9

一般論ではサーバー側でもチェックした方が良いでしょうね。ただ、私の場合、以下の条件を満たす場合、サーバー側での長さチェックは意図的に省略しますね。

• 事前チェックが機能する、JavaScriptが動作していることがほぼ保証できる。
• Webサーバーである程度長さ制限がしてある(DoS対策として)。
• パラメータクエリなど、SQLインジェクション対策がしてある。
• 文字が長すぎる場合、DB側でエラーになることが分かっている。
• エラーになってもデータ不整合は起きない。もう一度実行すればリカバリーできる。

まず起こらない無駄なエラーチェックを機械的に延々と書くと、下手すると本来の処理よりエラーチェックのコードの方が多いなんてことになりかねません。そうなると保守性が著しく低下します。私の場合、保守性の高さに特に気を配っているので、データ不整合、セキュリティ、変なエラーメッセージが出てユーザーが混乱、これらを回避する必要最小限のチェックに留めるようにしてます。私のような考えは特殊だし、このような書き方をするのは凄く大変です。全体のデータの流れ、チェックのされ方を全部計算しないとできませんので。

Aさんが普段バグがほとんどない、信頼性の高い、保守性の高いコードを書く人なら、その人は計算して書いているから考え方を学んだ方が良いし、逆ならコーディングルールとして強制した方が良いでしょう。結局、その方のレベルや考え方次第だと思います。

Comments

[退会済みユーザー]

現時点で高評価は3、低評価は4になってます。私の考え方は「当たり前」と思う人と「おかしい。けしからん。」と思う人の両方が存在するようです。恐らくベースとなる知識、考え方、立場が違うのだと思いますが、こう言うのは本当に珍しいですね。

[momon-ga]

NullReferenceExceptionが出るからnullチェックは不要ていうのに賛同できるかどうかの違いかなぁ。
チェックすれば、DBサーバへの通信はなくなるし、エラーログはでないし、エラーオブジェクトも作成されない、システムエラーが発生しないので、ログ検知もヒットしないとか、それなりのメリットありますからね。

Answer 10

Aさんがルーズすぎるんでしょうね。
サーバ側で一切防がないで、"何らかの理由でシステムエラーが返却されるから問題ない"スタンスなのでしょうか。

Answer 11

BAが出ていますが考え方を整理するために書いてみます。

バリデーションチェックは大きく分けて３つのフェーズがあると思います。
すなわち、ブラウザ・（サーバー）アプリケーション・データベースです。

基本はアプリケーションレベルのチェックでしょう。要件が許せば、長いテキストは勝手にぶった切ったり、範囲外の数値を最大値にぶった切ったりの乱暴も許します。これはデータベースに格納できるサイズであってもアプリケーションの要件で決めるべき内容です。すべての制約を管理できるのはアプリケーションでしかできず、ほかで管理すると記述が分散して管理が難しいからです。

データベースはアプリケーションが許容したすべてのデータを格納できるように設定できるべきです。このレベルでのエラーはユーザーのミスではなく、システムに問題点を抱えてると考えないとデータベースはビジネスロジックを定義することになり、管理上の混乱（バグの巣）になります。Aさんの組んだシステムがInsertでエラーになっているとすれば、感心できませんし、恐らく項目名とエラー内容をユーザーに伝えられていないか、他のエラーでも同じメッセージになっていないか心配してしまいます。

また、データ構造と関係のない制約をテーブル定義に入れるとシステムの拡張が難しくなります。データベースの変更はアプリケーションの変更よりコスト高なのです。

ブラウザ上のバリデーションは全く別の問題への対処になります。すなわち、アプリケーションでのバリデーションができている上で、ユーザーが入力中に誤りに気づく様にです。本気でユーザーがそれを入力しようとすると入力できてしまうので、その点でAさんの指摘は正しいとおもいます。

あと、Aさんが鼻で笑ったのは納得させる自身がないので感情や立場などで押し切ろうとしたんだと思います。つまり、あまり気にしなくて良いと思います。

だからと言って間違っていると決めつけるのも違うかもしれません。手間と効果が釣り合わないことは多く、手間の説明は難しいものです。