使用して、ステートメントオブジェクトを作成します。まれな状況で、プリペアドステートメントがパフォーマンスの低下を招くことがあります。(プリペアドステートメントを使用するのではなく、後述するように、データベース固有のエスケープ処理ルーチンを使用します)。使用して、同じデータベースクエリを実行します。場合は、もっと簡単になります。クエリの作成と実行の部分は変更しません。使用して、クエリにパラメーターを渡すだけでよいのです。含めて、ほぼすべての言語でパラメーター化されたクエリのインターフェイスがサポートされています。インジェクションと呼びます)。サポートされているため、この問題を回避できます。開発者は、プリペアドステートメントのアプローチを好む傾向があります。コードがアプリケーション内に収まるためです。これにより、アプリケーションは相対的にデータベースに依存しなくなります。(ほとんどのストアドプロシージャ言語では、標準で安全な実装になります)。ステートメントを作成することだけです。ステートメントは、開発者が基準から大きく外れたことを行わない限り自動的にパラメーター化されます。保存され、アプリケーションから呼び出されるという点が異なります。インジェクションの対策においては同じ効果があるため、組織にとって最適になるほうのアプローチを選択する必要があります。生成が含まれていないという意味です。生成することはありません。生成は可能ですが、避ける必要があります。コードが注入されないように、入力検証を使用するか、適切なエスケープ処理を行う必要があります。これについては後述します。逃さず見つけ出す必要があります。その他のベンダーの同様の機能にも、同様の監査のガイドラインが必要になります。ストアドプロシージャがリスクの増加につながる状況もあります。権限を要件に応じて付与します。ストアドプロシージャには実行権限が必要になります。これは、既定では利用できない役割です。権限で実行するようになります。サーバーが侵害されると、それまで読み取りアクセスのみが許可されていた攻撃者は、当然ながらデータベースに対する権限をすべて手に入れることになります。このトピックについての詳細は、次を参照してください。使用して、同じデータベースクエリを実行します。ストアドプロシージャは、データベース内で事前定義されている必要があり、上記で定義したクエリと同じ機能を実装している必要があります。使用して、同じデータベースクエリを実行します。ストアドプロシージャは、データベース内で事前定義されている必要があり、上記で定義したクエリと同じ機能を実装している必要があります。番目の技法では、ユーザー入力をエスケープしてからクエリに取り入れます。インジェクションを防止できるという保証はできません。この技法は、レガシーコードをコストをかけずに改造する場合にのみ慎重に使用するようにしてください。ゼロから作成するアプリケーションや、低いリスク許容度を要求するアプリケーションは、パラメーター化されたクエリを使用して作成するか、書き直す必要があります。この技法は、次のように動作します。以上サポートしています。インジェクション脆弱性の可能性を回避することになります。