クライアント側とサーバー側のどちらの検証を行うのが良いですか?
私たちの状況では、使用しています
私が行う検証の多くは、ユーザーが入力したデータを検証することです。たとえば、keypressイベントを使用して、テキスト ボックス内の文字を防止し、最大文字数を設定し、数字が範囲内にあるようにします。
クライアント側よりもサーバー側の検証を行う利点はありますか?
素晴らしい答えはみんなです。私たちが持っているウェブサイトはパスワードで保護されており、小規模なユーザー ベース (<50) 向けです。JavaScript を実行していない場合は、忍者を送信します。しかし、万人向けのサイトを設計するのであれば、両側で検証を行うことに同意します。
他の方もおっしゃっていますが、両方やるべきです。理由は次のとおりです。
平均的なユーザーにより良いフィードバックを提供できるため、最初にクライアント側で入力を検証する必要があります。たとえば、無効な電子メール アドレスを入力して次のフィールドに移動した場合、すぐにエラー メッセージを表示できます。そうすれば、ユーザーはフォームを送信する前にすべてのフィールドを修正できます。
サーバーでのみ検証する場合、フォームを送信し、エラー メッセージを取得して、問題を突き止めようとする必要があります。
(この問題は、サーバーがユーザーの元の入力を入力してフォームを再レンダリングすることで緩和できますが、クライアント側の検証は依然として高速です。)
JavaScript を簡単にバイパスして危険な入力をサーバーに送信できる悪意のあるユーザーから保護できるため、サーバー側で検証する必要があります。
UI を信頼することは非常に危険です。UI を悪用できるだけでなく、UI をまったく使用していないか、ブラウザさえも使用していない可能性があります。ユーザーが手動で URL を編集したり、独自の Javascript を実行したり、別のツールで HTTP 要求を微調整したりした場合はどうなるでしょうか? curlたとえば、スクリプトから、またはスクリプトからカスタム HTTP 要求を送信するとどうなるでしょうか?
(これは理論上の話ではありません。たとえば、ユーザーが各会社の検索フォームに入力したかのようにリクエストを送信することで、ユーザーの検索を多くの提携航空会社、バス会社などに再送信する旅行検索エンジンに取り組み、収集して並べ替えました。POSTこれらの会社のフォーム JS は実行されませんでした.返された HTML でエラー メッセージを提供することが私たちにとって重要でした.もちろん、API があればよかったのですが、これは私たちがしなければならなかったことです. )
それを許可しないことは、セキュリティの観点からナイーブであるだけでなく、非標準でもあります。クライアントは、任意の方法で HTTP を送信できるようにする必要があり、正しく応答する必要があります。これには検証が含まれます。
サーバー側の検証も互換性にとって重要です。ブラウザを使用している場合でも、すべてのユーザーが JavaScript を有効にしているわけではありません。
データベースの現在の状態に依存するため、サーバー側のアプリケーション コードでは適切に実行できず、クライアント側のコードではまったく不可能な検証がいくつかあります。たとえば、「他のユーザーがそのユーザー名を登録していない」、「あなたがコメントしているブログ投稿がまだ存在している」、「リクエストした日付と重複する既存の予約がない」、または「アカウントの残高にその購入をカバーするのに十分な残高がある」などです。 ." 関連データに依存するデータを確実に検証できるのは、データベースだけです。開発者は定期的にこれを台無しにしますが、PostgreSQL はいくつかの優れたソリューションを提供します。
はい、クライアント側の検証は常に完全にバイパスできます。より良いユーザー エクスペリエンスを提供するクライアント側と、取得した入力が実際に検証され、クライアントによって検証されたと思われるだけではないことを確認するサーバー側の両方を行う必要があります。
非常に重要なので、繰り返します。
サーバー上で常に検証する
ユーザー応答性のために JavaScript を追加します。
クライアント側の検証よりもサーバー側の検証を行う利点は、クライアント側の検証をバイパス/操作できることです。
要するに、常にサーバー側を検証し、クライアント側の検証を追加の「追加」として検討して、エンド ユーザー エクスペリエンスを向上させます。
サーバー上で常に検証する必要があります。
また、クライアントでの検証はユーザーにとっては便利ですが、まったく安全ではありません。
サーバー側の検証を実行し、各フィールドの検証結果を含む JSON オブジェクトを送り返すことができます。これにより、クライアントの Javascript を最小限に抑え (結果を表示するだけ)、クライアントとサーバーの両方で同じことを繰り返すことなく、ユーザー フレンドリーなエクスペリエンスを維持できます。
うーん、まだ答える余地はある。
Rob と Nathan からの回答に加えて、クライアント側の検証が重要であることを付け加えておきます。Web フォームに検証を適用する場合は、次のガイドラインに従う必要があります。
どちらの種類の検証もそれぞれの範囲で重要な役割を果たしますが、最も強力なのはサーバー側です。ある時点で 10,000 人のユーザーを受信した場合、Web サーバーに送信されるリクエストの数を確実にフィルタリングすることになります。無効な電子メール アドレスなどの 1 つの間違いがあった場合、彼らはフォームを再度ポストバックし、ユーザーにそれを修正するように求めます。これにより、サーバー リソースと帯域幅が確実に消費されます。そのため、JavaScript 検証を適用することをお勧めします。JavaScript が無効になっている場合、サーバー側の検証が役に立ちます。ウェブサイトの 99.99% が JavaScript を使用しており、最近のすべてのブラウザーで JavaScript がデフォルトで有効になっているため、誤って無効にしたユーザーはごくわずかだと思います。
クライアントとサーバーの両方の検証を実装して、プロジェクトをより安全に保つことをお勧めします....いずれかを選択する必要がある場合は、サーバー側の検証を使用します。
ここでいくつかの関連情報を見つけることができます https://web.archive.org/web/20131210085944/http://www.webexpertlabs.com/server-side-form-validation-using-regular-expression/
簡単な検証を行う場合は、クライアントで行うのが最善です。これにより、ネットワーク トラフィックが節約され、サーバーのパフォーマンスが向上します。パスワードなど、データベースからのデータのプルを含む検証が複雑な場合は、データを安全にチェックできるサーバーで行うのが最善です。