5
データ入力検証-どこ？いくら？[閉まっている]
データ入力の検証は、常に私にとって非常に内部的な闘争でした。 レガシーアプリケーションリライトプロジェクトに実際のセキュリティフレームワークとコードを追加する寸前（これまでのところ、カードキャッスルに強力なレガシーセキュリティコードとデータ検証を保持している）、私はどのくらい検証すべきか、どこなど プロのJava開発者としての5年間で、データ入力の検証とセキュリティ対策のための個人ルールを作成し、改良しました。私は自分の方法を改善したいので、皆さんからいくつかのアイデアを聞きたいと思います。一般的なルールと手順は問題ありませんが、Java固有のものも同様です。 要約すると、これらは私のガイドライン（3層のWebアプリケーションスタイルで公開）であり、簡単な説明があります。 第1層のクライアント側（ブラウザ）：最小限の検証、不変のルールのみ（必須の電子メールフィールド、1つのアイテムを選択する必要があるなど）。「6〜20文字」などの追加検証の使用頻度が少なくなります。これにより、変更のメンテナンス作業が増加します（ビジネスコードが安定したら追加できます）。 第1層サーバー側（Web通信処理、「コントローラー」）：このルールはありませんが、ここではデータ操作とアセンブリ/解析エラーのみを処理する必要があると考えています（誕生日フィールドは有効な日付ではありません）。ここにさらに検証を追加すると、簡単に本当に退屈なプロセスになります。 第2層（ビジネス層）：堅実な検証、それ以下。入力データ形式、範囲、値、メソッドをいつでも呼び出せない場合の内部状態チェック、ユーザーの役割/権限など。できるだけ少ないユーザー入力データを使用し、必要に応じてデータベースから再度取得します。取得したデータベースデータも入力と見なす場合、特定のデータが信頼できないか、DBで十分に破損していることがわかっている場合にのみ検証します。 第3層（データ層/ DAL / DAO）：データにアクセスするのはビジネス層のみであるため、ここでは多くの検証が必要とは考えられません（「param1がtrueの場合、param2はnullであってはならない」などの場合に検証します）。ただし、「ここ」を意味する場合、「データベースにアクセスするコード」または「SQL実行メソッド」を意味することに注意してください。データベース自体はまったく逆です。 データベース（データモデル）：適切なプライマリキー、外部キー、制約、データ型/長さ/サイズを使用して、DB上の不正なデータや破損データを可能な限り回避するために、十分に考慮し、強力かつ自己強化する必要があります/ precisionなど-独自のプライベートディスカッションがあるため、このトリガーは除外します。 初期のデータ検証は優れており、パフォーマンス面でも優れていることは知っていますが、繰り返しデータ検証を行うのは退屈なプロセスであり、データ検証自体は非常に面倒です。これが、非常に多くのコーダーがそれをスキップするか、途中でやる理由です。また、常に同期されていない場合、重複する検証はすべてバグの可能性があります。これらは、時間、帯域幅、CPU、ケースバイケースで処理される例外を犠牲にして、ほとんどの検証をビジネス層まで許可することを好む主な理由です。 それで、あなたはこれについてどう思いますか？反対意見ですか？他の手順はありますか？そのようなトピックへの参照？寄付はすべて有効です。 注：物事のJavaの方法を考えている場合、私たちのアプリはSpring MVCとMyBatisを使用したSpringベースです（パフォーマンスと不良データベースモデルはORMソリューションを除外します）。Spring SecurityをセキュリティプロバイダーとJSR 303（Hibernate Validator？）として追加する予定です。 ありがとう！ 編集：第3層に関する追加の明確化。