フロントエンドとサーバーでのバリデーション責務分解

はじめに 先日、Xでこんな投稿が話題になっていました。 実際のサイトを見ていないため詳細は不明ですが、事象としてはフロントエンドのJavaScriptだけでバリデーションを実装し、サーバーサイドに同等以上のバリデーションがなかったケースです。 DevToolsで回避できるということは、悪意あるユーザーが不正なデータを送信できてしまいます。 サーバーサイドではすべてのバリデーションを実装するべきです。セキュリティの観点でも、ドメインの正当性を保つ意味でも、サーバーは最後の砦となります。 一方で、フロントエンドのバリデーションについては、どこまで実装すべきか判断が難しいところです。本記事では、この点について考えを整理してみます。 バリデーションの責務を整理する 前提を決めておきます。 サーバーサイドバリデーションは絶対 サーバーサイドのバリデーションは必須です。これは絶対に省略できません。 理

[Kil]

すごく当たり前のことを、当たり前のように書いているだけではあるけど、簡潔によくまとまっていると思う。

[xlc]

バックエンドでチェックするのでフロントエンドは補助というのが古典的回答だが、コードを共通化しようとするとチェックにAPIを使うなどを考えたくなるよね。

[soxandcity]

サーバーサイド内でもバリデーションはレイヤーで分けるよね。ユーザー入力の検証とビジネスロジックの不変条件担保等。フロントも含めてそれぞれのレイヤーでやるべきことをやるだけではある。

[rryu]

結局、フロントエンドのバリデーションはあくまでもユーザーインターフェースの為のものなので、普通にやってもバックエンドでエラーになるものをフロントエンド側で頑張ると逆に良くない結果になるという。

[kazkun]

責任分界じゃなくて分解なのね。まあ間違いとも言えないけど。

[repon]

バックエンドで全てが完結したうえで、バリデーションデータなどはAPIで送ってくるのが理想。フロントエンドは余計なことをせず、ユーザーに負担をかけずに入力データを素直にバックエンドに送るのが責務

[Eiichiro]

確かにバリデーションの目的が違うから、実装の共通化もしなくて良いと思った。 なぜ共通化したくなっちゃうんだろう？

[BOOOOOOOON]

alway valid-domain modelの思想に従えばいいのである

[sigwyg]

フロントエンドはUXなので、バックエンドでセキュリティとデータ整合性を確保すべき定期。WordPressみたいなPHP案件だと、DB経験ないフロントエンド技術者がうっかり実装しちゃうことも多いので注意

[taruhachi]

複雑なバリデーションルールになる時や業務要件で変わる時にフロントとバックエンドで二重に持ちたくない時はある。新ルールのパスワードでは昔作ったパスワードと違ってフロントで弾かれると入力できなくなるとか。

[komutan1]

バックはデータの整合性のために、フロントはUX向上のために、という観点で両方で好きなバリデーションやればいいと思う

[PrivateIntMain]

前の人がやってるからヨシ！ではなくて自分の身は自分で守ろうという話。アクセス経路が限定されてるからDBの権限なんかフルコントロールでええやろとならんのと同じ。

[n314]

vmwareのアカウントがbroadcomに移行したんだけど、日本語が文字化けしてるしフォームがdisabledなので変更もできなくて詰んだ。なのでdisabled消して進めたよ。元tweetも単純にフロントか仕様のバグじゃない？

[ryudenx]

フロントのバリデーションはUI/UXのために実装すべきで、バックのバリデーションはセキュリティのために実装すべき

[kakusuke07]

なぜみんな、フロント側がバグってた可能性を考えないんだろう

[pico-banana-app]

フロントのバリデーションなんて簡単に突破されるから、サーバー側のチェックは絶対必須だよなｗ

[Xibalba]

よく言われるやつ “フロントエンドとサーバーでのバリデーション責務分解”