虽然这种对关键数据的简易访问已经极大地提高了工作人员的效率，并提高了顾客的购买欲，但它也为关键数据库打开了巨大的风险之门。不幸的是，许多风险是由缺乏资源的开发人员带来的，他们往往无法得到足够的时间、金钱、教育以及来自管理人员的支持，因而无法设计开发没有漏洞的应用程序。

　　在上述资源无法到位时，开发人员往往会犯这些错误：

　　1、过于相信输入方法

　　当今开发人员将数据库置于风险之中的一种重要方法是，使其应用程序遭受SQL注入攻击。当开发人员过于相信用户输入时，往往会出现SQL注入漏洞。

　　如果不对其进行验证，例如，如果不验证一个只接受数字的电话号码字段，开发者有可能允许黑客对数据库进行终端访问。例如，插入到表单域中的单引号有可能过早地关闭应用程序本应实施的合法SQL查询，从而使攻击者可以构建并提交新的查询。

　　解决这种问题的好方法之一是使用参数化查询。

　　参数化查询可以防止攻击者改变查询中的逻辑或代码，并阻止大多数SQL注入攻击。参数化查询出现的时间像数据库一样长，它不像安全的其它许多领域，使用参数化查询也是保障性能和代码可维护性的佳方法。

　　但开发人员不应当停留于此。还要对用户输入进行净化和验证，因为有时参数化并不可行。即使可行，攻击者也可以将非验证的输入用于其它恶意目的，如跨站脚本攻击等。

　　老套且糟糕的问题是，不对用户输入进行净化，即在对数据库运行查询之前，不剔除用户输入中并不需要的字符，例如不移除撇号或分号。

　　2、数据库错误消息显示给终端用户

　　在应用程序的SQL查询出现问题时，如果开发人员允许弹出特定的错误消息，这也许有助于诊断，但这也向攻击者提供了一个探查后端数据库的内部工作机制的很好途径。

　　通过得到的数据库错误消息，攻击者会了解数据库的组织结构和应用程序查询等许多重要信息，从而更容易展开攻击。

　　错误消息可以泄露关于应用程序连接的数据库类型、底层设计等的线索。

　　这种错误会为盲目SQL注入攻击打开大门，所以开发者应当在页面显示一般性的错误消息而非特定消息。

　　3、轻率地对待口令

　　为了图方便，许多开发者用多种不安全的方法来轻率地对待用户口令。例如，他们可能将口令硬编码到应用程序中。

　　明显的数据库风险之一在于硬编码口令和存在于配置文件中的口令。这两种设计选择都依赖于这种脆弱的安全性，他们假定攻击者不会访问这种信息，因而开发者并不关心文件或其中信息的安全性。

　　同样危险的还有将口令存放到纯文本中的方法，其中包括不对用户输入的口令进行哈希，以及并不对哈希加盐（加盐：将随机位添加到哈希中）。

　　此外，还有不健全的口令管理，没有将强健的口令认证构建到应用程序中。

　　4、使所有的连接都是“超级”的

　　同样的，许多开发者通过“根”或其它一些超级用户账户来将应用程序连接到数据库中，从而将数据库置于风险之中。这通常是一个与硬编码口令的应用程序有关的问题，这是因为在这些情况下很难实施适当的特权管理。

　　普通的应用操作很少需要由“超级”特权所许可的访问，允许应用程序使用超级特权用户，会为不适当的非授权活动创造机会。所有的应用程序都应当使用少特权的用户凭证连接到数据库。