クライアント側の検証では不十分なのはなぜですか？
私が見た ここ それ：
おそらくすでにご存知のように、クライアント側の検証だけに依存することは非常に悪い考えです。常に適切なサーバー側の検証も実行してください。
サーバー側の検証が必須である理由を説明できますか？
クライアント側の検証-ここでWebページについて話していると思います-は JavaScript に依存しています。
JavaScriptを利用した検証は、ユーザーのブラウザでオフにしたり、スクリプトエラーが原因で失敗したり、手間をかけずに悪意を持って回避したりする可能性があります。
また、フォーム送信のプロセス全体が偽造される可能性があります。
したがって、サーバー側に到着するものがクリーンで安全なデータであるという保証はありません。
サーバーアプリケーションの作成には簡単なルールがあります：ユーザーデータを絶対に信用しないでください。
悪意のあるユーザーが意図しない方法でサーバーにアクセスしていると常に想定する必要があります（たとえば、この場合、意図したWebページではなくcurlを介した手動クエリを介して）。たとえば、WebページがSQLコマンドを除外しようとした場合、攻撃者はSQLコマンドで入力を渡すのが適切な攻撃ベクトルである可能性があるという良いヒントをすでに持っています。
基本的なJavaScriptを知っている人なら誰でも、クライアント側を回避できます。
クライアント側は、ユーザーエクスペリエンスを向上させるために使用されます（検証するためにページをリロードする必要はありません）
あなたが話しているクライアントはあなたが話しているクライアントではないかもしれませんthinkあなたが話しているクライアントではないので、あなたが求めている検証を無視しているかもしれません。
Webコンテキストでは、ユーザーがブラウザーでJavaScriptを無効にしている可能性があるだけでなく、ブラウザーとまったく通信していない可能性もあります。POSTしているボットからフォーム送信を取得している可能性があります。フォームをまったく見たことがなくても、送信URLにアクセスできます。
より広い文脈では、実際のクライアントが決して送信しないデータを送信しているハッキングされたクライアント（たとえば、FPSゲームのエイムボット）、またはワイヤープロトコルをリバースエンジニアリングした誰かによって作成された完全にカスタムのクライアントを処理している可能性がありますこれは、実行することを期待している検証については何も知りません。
JavascriptおよびWebクライアントに固有でなく、問題にさらに広く対処するために、サーバーは（基盤となるデータベースと組み合わせて）独自のデータを維持する責任を負う必要があります。
クライアント/サーバー環境では、サーバーは、多くの異なるクライアント実装がサーバーと通信する可能性があるという事実に対応できる必要があります。トレードエントリーシステムを考えてみましょう。クライアントは、GUI（トレードエントリーシステムなど）および（たとえば）データアップロードクライアント（.csvファイルから複数のトレードをロードする）である可能性があります。
クライアントの検証はさまざまな方法で実行できますが、すべてが正しく実行されるとは限りません。したがって、サーバーは必ずしもクライアントデータを信頼し、整合性チェックと検証自体を実行する必要はありません。
攻撃者が独自のフォームを投稿した場合。
ユーザーエージェント（ブラウザなど）は偽物である可能性があるためです。任意のヘッダーとコンテンツを含むHTTPリクエストを作成するカスタムアプリケーションを作成するのは非常に簡単です。それは本物のブラウザであるとさえ言えます—違いを見分ける方法はありません。
リクエストの内容を確認するだけで、チェックしないと有効かどうかわかりません。
JavaScriptをオフ/編集できます。
一般に、アプリのすべての部分が独自のチェック/検証を行うのが最善です。
クライアント側のチェックは、ユーザーエクスペリエンスを最大化し、何かを修正する必要があるというクライアントへのフィードバックを高速化し、サーバー側のチェックで発生する問題の量を減らすのに役立ちます。
次に、サーバー側コードの主要な移行ポイントごとに、そこでもチェックを行う必要があります。アプリケーションコード内の入力を、できれば ホワイトリスト入力検証 を介して検証し、データベースとの対話でパラメーター化されたクエリを使用して、問題が発生しないようにします。
クライアント側の検証では、検証されていないデータがサーバーに到着することが保証されないため、サーバー側の検証は必須です。
アクションの範囲が非常に制限されているため、クライアント側の検証では不十分です。検証は、ブラウザのユーザーインターフェイスでのみ実行されます。
Webサーバーは、ブラウザからデータを含むHTTPリクエストを「リッスン」して受信し、処理します。
悪意のあるユーザーは、さまざまな方法で悪意のあるHTTPリクエストを送信できます。ブラウザも必要ありません。
ブラウザでJavaScriptを使用して実行されるクライアント側の検証は、重要なユーザビリティ、ユーザーインターフェイスの拡張機能です。しかし、それは悪意のあるデータの送信を妨げませんサーバーに送信されるHTTP要求を構築するブラウザーのデフォルトの動作を回避する方法を知っているユーザーによるものです。これは、cURLなどを使用して、一部のブラウザプラグインで簡単に実行できます。
クライアント側の検証は、クライアントが間違ったデータを入力するのを防ぐためのものです。サーバー側の検証は、サーバーが間違ったデータを処理するのを防ぐためのものです。その過程で、提出プロセスにある程度のセキュリティも導入されます。
無効な場合、データを投稿するエンティティ以外の人に害を及ぼす可能性のあるデータに対して、サーバー側の検証を実行する必要があります。クライアント側の検証は、無効なデータがそれを投稿するエンティティ以外の人に悪影響を及ぼさない場合に適している可能性があります。悪いデータによる悪影響がそれを投稿するエンティティを超えて広がらないことが確実でない限り、サーバー側の検証を使用して、破壊者やその他の不正なクライアントから身を守る必要があります。
バディ、ブラウザでJavaScriptをオフにすると、検証が無効になったとします。次に、彼がそのフォームを介してサーバー側に悪意のあるコンテンツを投稿した場合。これは、SQLインジェクションやxssなどの深刻な脆弱性やその他のタイプの問題につながります。したがって、クライアント側のjavascript検証を実装する場合は注意してください。
ありがとうございました
クライアント側の検証は、安全なブラウザ、クライアント側の言語、またはHTML 5を前提としています。これらの要素はすべて無効になっている、部分的に使用できない、または単に実装されていない可能性があります。あなたのウェブサイトはすべての人から、すべてのブラウザで使用されなければなりません。サーバーサイド言語の方が安全であり、バグでない場合は、検証が確実に安全で適切になります。