不正なデータ入力の防止

Question

データ検証をデータベース エンジンの制約に完全に委任するのは良い方法でしょうか?

アプリケーションからのデータを検証しても、別のソフトウェア (おそらく別のチームによって別の言語で書かれた) からの無効な挿入を防ぐことはできません。データベース制約を使用すると、無効な入力データについて心配する必要がある箇所が減ります。

データベースとアプリケーションの両方に検証を入れると、アプリケーションの数を誰が知っているかに応じてコードを更新する必要があり、人的エラーが発生する可能性が高まるため、メンテナンスが退屈になります。

フリーソフトウェアプロジェクトのコードを見ると、これがあまり行われていないように見えます。

Answer 1

可能であれば、データベース内で検証ルールを指定し、それらのルールをフロントエンドに組み込むフレームワークを使用または作成することをお勧めします。ASP.NET Dynamic Data はこれに役立ちます。また、それをさらに簡単にする商用ライブラリがいくつかあります。

これは、単純な入力検証 (数値や日付など) と、外部キーによって制約されるような関連データの両方に対して実行できます。

要約すると、アイデアは 1 か所 (ほとんどの場合はデータベース) でルールを定義し、それらのルールを強制するコードを他のレイヤーに配置することです。

Answer 2

入力時に検証します。データベースに入れる前に再度検証してください。また、不正な入力を防ぐためにデータベースに制約を設けます。これらすべてにもかかわらず、間違いなく、不正なデータがデータベースに入力される可能性があるため、使用するときにもう一度検証してください。

毎日、Web アプリがすべての検証をフォーム内で行っているか、さらに悪いことに Javascript を使用してハッキングされているようですが、人々はそれを回避する方法を見つけました。それを防ぐ必要があります。

パラノイア？自分？いや、ただ経験しただけです。

Answer 3

ロジックをデータベースに任せる場合の欠点は、その特定のサーバーの負荷が増加することです。Web サーバーとアプリケーション サーバーは外部への拡張が比較的簡単ですが、データベースには特別なテクニックが必要です。一般的なルールとして、計算ロジックの多くをアプリケーション層に配置し、データベースとのやり取りをできるだけシンプルにすることをお勧めします。

そうは言っても、アプリケーションではそのような重大なスケーラビリティの問題を心配する必要がない可能性があります。あなたがいる場合 ある データベース サーバーの負荷が当面は問題にならない場合は、データベースに制約を設定してください。これにより、検証ロジックが中央の場所に保持されることで、システム全体の組織化と簡素化が向上するというのは、まったく正しいことです。

Answer 4

入力による SQL インジェクション以外にも懸念事項があります。ユーザー入力を受け入れるときは常に、可能な限り防御的な姿勢を取る必要があります。たとえば、ユーザーは画像へのリンクをテキスト ボックスに入力できますが、これは実際には厄介なものを実行する PHP スクリプトです。

アプリケーションを適切に設計すれば、すべての入力を苦労してチェックする必要はありません。たとえば、ほとんどの作業を処理してくれる Forms API と、ほぼ同じことを行うデータベース層を使用できます。

これは、脆弱性の基本的なチェックに適したリソースです。

http://ha.ckers.org/xss.html

Answer 5

ユーザーやアプリケーションに有意義な検証を提供するには、データがデータベースに到着する頃には遅すぎます。データベースにこんなことをさせたくない 全て 検証すると処理が大幅に遅くなり、データベースではロジックが明確に表現されないためです。同様に、成長するにつれて、データベース トランザクションを補完するために、より多くのアプリケーション レベルのトランザクションを作成することになります。

Answer 6

クエリが失敗したときに何が起こるかによっては、これは悪い習慣になる可能性があると思います。たとえば、データベースがエラーをスローし、それがアプリケーションによってインテリジェントに処理される場合は、問題はないかもしれません。

一方、アプリに検証を何も入れなかった場合、不正なデータは存在しない可能性がありますが、ユーザーは保存されないものを入力したと考える可能性があります。

Answer 7

他の目標を損なうことなく、データベース側でできる限り多くのデータ検証を実装します。たとえば、速度が問題になる場合は、次のことを検討するとよいでしょう。 ない 外部キーなどを使用するさらに、一部のデータ検証は、電子メール アドレスに有効なドメインが含まれていることを確認するなど、アプリケーション側でのみ実行できます。

Answer 8

データベースからデータ検証を行うことのもう 1 つの欠点は、すべてのケースで同じ方法で検証できるわけではないことです。実際、これはアプリケーション ロジック (ユーザー ロール) に依存することが多く、場合によっては検証を完全にバイパスしたい場合もあります (cron ジョブやメンテナンス スクリプト)。

Answer 9

データベースではなくアプリケーションで検証を行う方がうまく機能することがわかりました。もちろん、すべての対話はアプリケーションを経由する必要があります。データを操作する他のアプリケーションがある場合、そのアプリケーションは何らかの API (できれば REST) をサポートする必要があります。

Answer 10

正しい答えは一つではないと思いますが、それは用途によって異なります。

データベースのパフォーマンスがボトルネックになる可能性があり、非常に頻繁に使用されるシステムを使用する場合は、複数のサーバーで拡張しやすいフロントエンドに検証の責任を移すことをお勧めします。

複数のアプリケーションがデータベースと対話している場合、複数のアプリケーション間で検証ルールを複製して維持したくない場合があるため、データベースの方が適している可能性があります。

ユーザーがレコードを保存しようとしたときに検証警告が表示されるだけでなく、より滑らかな入力画面が必要な場合もあります。データが入力されてフォーカスが失われた後でフィールドを検証したい場合もあるでしょう。または、ユーザーが入力しているときでも、検証の失敗/合格に応じてフォントの色が変更されます。

制約に関連するのは、疑わしいデータの警告です。私のアプリケーションでは、データベースにハード制約があります (例:生年月日より前に仕事を開始することはできません）が、フロントエンドでは、おそらく正しいが疑わしいデータ（例:8 歳の子供が仕事を始めます）。