ちょいと前からですが、断続的に大規模な SQL injection 攻撃が続いています。
よくある対策としては、stored procedure 利用しろ！とか、parameterized query 利用しろ！とか ad-hoc query 利用する場合は sanitizing しろ！とか。望ましい順番は stored procedure > parameterized query > ad-hoc query with sanitizing になるわけですが、stored procedure 以上により望ましい方法があります。
SQL injection って何が問題なんでしょう？
そう、本来は許可されるべきでない user が不正に data へ access できてしまうことが問題なんです。あれ？これってもろに access control の話ですよね？ 大抵の DBMS には当然 DBMS の access control 機能があります。そう、これを厳密に適用している状態であれば、SQL injection されたところで data に access する段階で確実にはじかれます。また、application 側で対策するよりも遥かに容易に制限を課すことができるのも利点ですね。
でも、一般に DBMS の access control 機能ってそれほど利用されていないじゃないの？と思われる方も多いと思います。これはなぜでしょう？
一つ目の要因として、DB に access する user を分けると resource 消費が増えるというのがあります。利用する DBMS によって異なりますが、connection pooling ができなくなるとか多くの場合 performance 面で不利になる点は否めないでしょう。これが一番の要因になっているようですね。
二つ目は user 管理の問題です。DB に access する user を分けるわけですから、DB もしくは DB で利用する認証 server に user account を作成する必要があります。これを嫌っている人も多いみたいですね。でも、これ自動化するのはそんなに難しくないと思うんだけどなぁ。独自の認証利用している場合が多いと思いますが、その強度・管理面まで考えると正直逆転するんじゃないかと思います。
まあ、そういうこともあって現状では DBMS の access control を利用していることが多いとは言えませんが、より確実な access control 以外にも DB への接続 user を分ける利点があります。
それは、traceability の確保です。DB へ接続する user を共有している場合、当然ですが DB 側ではどの user が行った操作なのかわかりません。これでは監査できているとは言えませんよね。ちゃんとした監査を要求される system では、どの user (個人) が行った操作か？ というのが識別できないといけません。User を共有した場合、これを application 側で DB に書き込む処理を追加しなければなりません。これは正直負担が大きいです。では user を分離した場合ではどうなるでしょう？ DBMS 側の機能で要求される監査を実施できることが多いです。いちいちゴリゴリ coding する必要がないので楽になりますね。
まあ、どの方法を選択するかは perfomance, security は当然として、開発費用、運用管理費用等まで考慮する必要があります。DB というととかく perfomance のみに目が行きがちですが、他の要因も検討対象に加え再評価してはいかがでしょうか。