クライアント側とサーバー側の両方の検証手法を使用していますか？

連絡先フォームなどを介してユーザーからの入力を検証するときに、クライアント側とサーバー側の両方の検証手法を並べて使用していますか？

もしそうなら、それは本当に必要ですか？あなたはエンジニアリングを超えていますか？

はい、そうすべきです。

これにより、ユーザーがJavaScriptを無効にすることを防ぎながら、無駄なポストバックなしでユーザーのフィードバックを即座に維持できます。

これがASP.NET検証コントロールが機能する方法です。

他を使用せずに使用することには欠点があるので、それは確かに過剰設計ではありません。

もしそうなら、それは本当に必要ですか？

はい。

あなたはエンジニアリングを超えていますか？

番号。

リッチなインターフェースの場合、フロントエンドの検証は即座にフィードバックを提供できます。

バックエンドは複数のフロントエンドで使用できます。そして、これはHTMLのみ（JavaScriptなし）のフォールバック計画の唯一の検証です。

私がセキュリティについて学んだ最初の基本の1つは、ハッカーがあなたのUIを決して使用しないということでした。

通常、クライアント側の検証は、独自のローカルバージョンのフォームがあり、それをサーバーに送信すれば、Webアプリで簡単にバイパスできます。

ただし、クライアント側の検証は、ユーザーエクスペリエンスを向上させ、検証を実行するためのサーバーへの不要なラウンドトリップを減らすのに役立ちます。

サーバー側の検証は最低限必要です。

また、間違っている可能性のある入力については、クライアント側のチェックも追加する必要があります。

例：メールがクライアント側とサーバー側の両方で正しくフォーマットされているかどうかを確認しますが、一意であるかどうかを確認するのはサーバー側のチェックです。

はい、両方を使用することは悪い考えではありません。単純なユーザー入力エラーがクライアント側でキャッチされる可能性がある場合は、データを送信してサーバーにバグを報告する前に、それらのエラーについてユーザーに伝えるのが理にかなっています。たとえば、ユーザーが「メール」フィールドにメールアドレスのように見えないものを入力したか、パスワードフィールドに5文字のみの文字列を入力し、サイトでパスワードを6文字以上にする必要があることがわかっている場合、サーバーに何かを送信する前に、それをユーザーに伝える必要があります。

2つの理由でサーバー上でまったく同じ検証を複製することも重要です。1）ユーザーがJavaScriptを無効にしている場合はどうなりますか？

2）ユーザーが悪意を持ってクライアント側の検証をバイパスしようとしましたが、これは非常に簡単です。