JavaScript：クライアント側とサーバー側の検証
クライアント側の検証とサーバー側の検証のどちらを行う方が良いですか？
私たちの状況では
- jQueryおよびMVC。
- ビューとコントローラーの間で渡すJSONデータ。
私が行う検証の多くは、ユーザーが入力したデータの検証です。たとえば、keypressイベントを使用して、テキストボックス内の文字を防ぎ、最大文字数を設定し、数値が範囲内にあることを設定します。
より良い質問は、クライアント側よりもサーバー側の検証を行う利点があると思いますか？
素晴らしい答えはみんなです。私たちが持っているウェブサイトはパスワードで保護されており、小さなユーザーベース（50未満）です。 JavaScriptを実行していない場合は、忍者を送ります。しかし、すべての人のためにサイトを設計していた場合、両側で検証を行うことに同意します。
他の人が言ったように、両方を行う必要があります。その理由は次のとおりです。
クライアント側
平均的なユーザーへのより良いフィードバックを与えることができるため、最初にクライアント側で入力を検証する必要があります。たとえば、無効なメールアドレスを入力して次のフィールドに移動した場合、すぐにエラーメッセージを表示できます。これにより、ユーザーはすべてのフィールドを修正できますbeforeフォームを送信します。
サーバーでのみ検証する場合は、フォームを送信し、エラーメッセージを取得して、問題の追跡を試みる必要があります。
（この痛みは、ユーザーの元の入力が入力された状態でサーバーにフォームを再レンダリングさせることで緩和できますが、クライアント側の検証は依然として高速です。）
サーバ側
悪意のあるユーザーから保護するを使用できるため、サーバー側で検証する必要があります。このユーザーはJavaScriptを簡単にバイパスして、危険な入力をサーバーに送信できます。
UIを信頼することは非常に危険です。 彼らはあなたのUIを悪用できるだけでなく、あなたのUIをまったく使用していないか、ブラウザさえ使用していない可能性があります。ユーザーがURLを手動で編集したり、独自のJavascriptを実行したり、HTTPリクエストを別のツールで調整したりするとどうなりますか？たとえば、curlまたはスクリプトからカスタムHTTP要求を送信するとどうなりますか？
（これは理論的なものではありません。たとえば、ユーザーがそれぞれの情報を入力したかのようにPOSTリクエストを送信することで、多くのパートナー航空会社、バス会社などにユーザーの検索を再送信する旅行検索エンジンで作業しましたこれらの会社のフォームJSは決して実行されず、返されたHTMLでエラーメッセージを提供することが重要でした。もちろん、APIはニースでしたが、これはそうでした私たちがしなければならなかったこと。）
これを許可しないことは、セキュリティの観点から単純であるだけでなく、非標準でもあります。クライアントは、希望するあらゆる手段でHTTPを送信できるようにし、正しく応答する必要があります。これには検証が含まれます。
サーバー側の検証は、compatibilityでも重要です。すべてのユーザーは、ブラウザを使用している場合でもJavaScriptが有効になっているわけではありません。
補遺-2016年12月
サーバー側のアプリケーションコードでは適切に実行することさえできず、クライアント側のコードではまったく不可能ですという検証がいくつかあります。これは、データベースの現在の状態に依存するためです。たとえば、「他に誰もそのユーザー名を登録していない」、「コメントしているブログ投稿はまだ存在する」、「既存の予約はリクエストした日付と重複していません」、「アカウントの残高は購入をカバーするのに十分です」 」 関連するデータに依存するデータを確実に検証できるのはデータベースのみです。開発者 通常はこれを台無しにします 、しかし PostgreSQLは優れたソリューションを提供します 。
はい、クライアント側の検証は常に完全にバイパスできます。より良いユーザーエクスペリエンスを提供するためにクライアント側と、クライアントが取得した入力が実際に検証されるだけでなく、実際に検証されるようにするために、サーバー側の両方を行う必要があります。
非常に重要なので、繰り返します。
サーバー上で常に検証
ユーザーの応答性のためにJavaScriptを追加します。
クライアント側の検証よりもサーバー側の検証を行うことの利点は、クライアント側の検証をバイパス/操作できることです。
- エンドユーザーはJavaScriptをオフにすることができます
- データは、あなたのサイトさえ使用していない誰かがあなたのサーバーに直接送ることができ、そうするように設計されたカスタムアプリで
- ページ上のJavascriptエラー（さまざまな原因が原因）により、検証の実行のすべてではなく一部が実行される可能性があります
要するに、常に、常にサーバー側を検証してから、クライアント側の検証を追加の「追加」として考慮し、エンドユーザーエクスペリエンスを向上させます。
あなたは必ずサーバーで検証する必要があります。
また、クライアントで検証を行うことはユーザーにとって素晴らしいことですが、まったく安全ではありません。
サーバー側の検証を行い、各フィールドの検証結果を含むJSONオブジェクトを送り返すことができます。クライアントJavascriptを最小限に抑え（結果を表示するだけ）、クライアントとサーバーの両方で繰り返す必要なくユーザーフレンドリーなエクスペリエンスを維持できます。
まあ、まだ答える余地があります。
RobとNathanからの回答に加えて、クライアント側の検証が重要であると付け加えます。 Webフォームに検証を適用するときは、次のガイドラインに従う必要があります。
クライアント側
- ウェブサイトで本物のユーザーからの本物のリクエストをフィルタリングするには、クライアント側の検証を使用する必要があります。
- サーバー側の処理中に発生する可能性のあるエラーを減らすには、クライアント側の検証を使用する必要があります。
- クライアント側の検証を使用してサーバー側のラウンドトリップを最小限に抑え、ユーザーごとの帯域幅とリクエストを節約する必要があります。
サーバ側
- クライアント側で正常に行われた検証が100％完全であると想定してはなりません。 50人未満のユーザーにサービスを提供していても関係ありません。どのユーザー/従業員が「悪」になり、適切な検証が行われていないことを知って何らかの有害な活動を行うことは決してありません。
- 電子メールアドレス、電話番号の検証、またはいくつかの有効な入力の確認に関して完璧であったとしても、非常に有害なデータが含まれている可能性があります。正しいか間違っているかに関係なく、サーバー側でフィルタリングする必要があります。
- クライアント側の検証がバイパスされた場合、サーバー側の検証は、サーバー側の処理に対する潜在的な損傷からあなたを救います。最近では、SQLインジェクションやその他の悪の恩恵を得るために適用される可能性のあるその他のテクニックの話を既に多く聞いています。
両方のタイプの検証は、それぞれのスコープで重要な役割を果たしますが、最も強力なのはサーバー側です。一度に1万人のユーザーを受信した場合、Webサーバーに着信するリクエストの数を確実にフィルタリングすることになります。無効なメールアドレスなどの間違いが1つでもあった場合は、フォームを再度投稿し、サーバーリソースと帯域幅を確実に消費するようにユーザーに修正を依頼します。したがって、JavaScript検証を適用する方が適切です。 JavaScriptが無効になっている場合、サーバー側の検証が役立ちます。Webサイトの99.99％がJavaScriptを使用しており、すべての最新のブラウザでデフォルトで既に有効になっているため、誤って無効にするユーザーが少ないと思われます。
クライアント側は、 HTML5入力タイプ および パターン属性 による基本的な検証を使用する必要があります。これらはユーザーエクスペリエンスを向上させるためのプログレッシブ拡張にのみ使用されます（< IE9とサファリ、しかし私たちはそれらに依存していません）。ただし、主な検証はサーバー側で行う必要があります。
私は、クライアントとサーバーの両方の検証を実装することを提案します。
2018年7月23日更新：次のリンクにはアクセスできなくなりました：
ここにいくつかの関連情報を見つけることができます http://www.webexpertlabs.com/server-side-form-validation-using-regular-expression/
JavaScriptは実行時に変更できます。
サーバー上で検証構造を作成し、これをクライアントと共有するパターンを提案します。
たとえば、両端で個別の検証ロジックが必要です。
inputsクライアント側の"required"属性
field.length > 0サーバー側。
ただし、同じ検証仕様を使用すると、両端で検証をミラーリングする冗長性（およびミス）がなくなります。
総誤差、系統誤差、ランダム誤差を区別する興味深いリンクに出会いました。
Client-Side validationは、グロスエラーとランダムエラーの防止に最適です。通常、テクスチャと入力の最大長。サーバー側の検証ルールを模倣しないでください。独自の大まかな経験則の検証ルールを提供します（例：クライアント側で200文字、強力なビジネスルールによって決定されるサーバー側でn）。
Server-side validationは、体系的なエラーを防ぐのに最適です。ビジネスルールを実施します。
私が関係しているプロジェクトでは、検証はajaxリクエストを介してサーバーで行われます。クライアントでは、それに応じてエラーメッセージを表示します。
さらに読む：全体的、体系的、ランダムなエラー：
https://answers.yahoo.com/question/index?qid=20080918203131AAEt6GO
クライアント側のデータ検証は、ユーザーエクスペリエンスを向上させるのに役立ちます。たとえば、自分のメールアドレスを間違って入力したユーザーは、リクエストがリモートサーバーによって処理されて入力ミスを知るまで待つ必要はありません。
それでも、攻撃者はクライアント側の検証をバイパスできるため（ブラウザをまったく使用しないこともあります）、サーバー側の検証が必要であり、悪意のあるユーザーからバックエンドを保護するための真のゲートでなければなりません。