質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

ただいまの
回答率

87.96%

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

解決済

回答 11

投稿

  • 評価
  • クリップ 7
  • VIEW 13K+

score 33

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

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

  • 気になる質問をクリップする

    クリップした質問は、後からいつでもマイページで確認できます。

    またクリップした質問に回答があった際、通知やメールを受け取ることができます。

    クリップを取り消します

  • 良い質問の評価を上げる

    以下のような質問は評価を上げましょう

    • 質問内容が明確
    • 自分も答えを知りたい
    • 質問者以外のユーザにも役立つ

    評価が高い質問は、TOPページの「注目」タブのフィードに表示されやすくなります。

    質問の評価を上げたことを取り消します

  • 評価を下げられる数の上限に達しました

    評価を下げることができません

    • 1日5回まで評価を下げられます
    • 1日に1ユーザに対して2回まで評価を下げられます

    質問の評価を下げる

    teratailでは下記のような質問を「具体的に困っていることがない質問」、「サイトポリシーに違反する質問」と定義し、推奨していません。

    • プログラミングに関係のない質問
    • やってほしいことだけを記載した丸投げの質問
    • 問題・課題が含まれていない質問
    • 意図的に内容が抹消された質問
    • 過去に投稿した質問と同じ内容の質問
    • 広告と受け取られるような投稿

    評価が下がると、TOPページの「アクティブ」「注目」タブのフィードに表示されにくくなります。

    質問の評価を下げたことを取り消します

    この機能は開放されていません

    評価を下げる条件を満たしてません

    評価を下げる理由を選択してください

    詳細な説明はこちら

    上記に当てはまらず、質問内容が明確になっていない質問には「情報の追加・修正依頼」機能からコメントをしてください。

    質問の評価を下げる機能の利用条件

    この機能を利用するためには、以下の事項を行う必要があります。

回答 11

+25

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

checkベストアンサー

+14

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

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/06/26 20:51

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

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

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

    キャンセル

  • 2017/06/26 20:59

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

    キャンセル

  • 2017/06/27 20:45

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

    キャンセル

  • 2017/06/27 20:53

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

    キャンセル

+7

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/06/26 20:50

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

    キャンセル

  • 2017/06/26 21:15

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

    キャンセル

+6

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

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

insert文でコケ

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+5

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

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

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

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

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/06/26 20:49

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

    キャンセル

+5

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+4

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

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

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+3

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

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

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

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

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

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

がんばってください。

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

+2

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

0

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

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

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

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

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

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

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

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

投稿

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

-2

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

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

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

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

投稿

編集

  • 回答の評価を上げる

    以下のような回答は評価を上げましょう

    • 正しい回答
    • わかりやすい回答
    • ためになる回答

    評価が高い回答ほどページの上位に表示されます。

  • 回答の評価を下げる

    下記のような回答は推奨されていません。

    • 間違っている回答
    • 質問の回答になっていない投稿
    • スパムや攻撃的な表現を用いた投稿

    評価を下げる際はその理由を明確に伝え、適切な回答に修正してもらいましょう。

  • 2017/07/07 23:11

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

    キャンセル

  • 2017/07/12 15:25

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

    キャンセル

15分調べてもわからないことは、teratailで質問しよう!

  • ただいまの回答率 87.96%
  • 質問をまとめることで、思考を整理して素早く解決
  • テンプレート機能で、簡単に質問をまとめられる

関連した質問

同じタグがついた質問を見る