5、相信存储过程是SQL注入的解决之道

　　当今的许多开发人员相信，存储过程是防止SQL注入的一种可靠方法。

　　事实上，如果存储过程自身的代码中包含漏洞，或者如果存储过程被以一种不安全的方式调用，它并不能防止SQL注入。

　　在存储过程中可以发生串的连接或并置。即使存储过程的调用是准备好的语句，如果在存储过程自身内部构建和执行查询，它也有可能易遭受攻击。

　　6、将调试代码留放到生产环境中

　　正如厨师在做完了美味佳肴之后要打扫厨房一样，开发人员必须在将程序投放到生产环境中之前，必须清理其代码，以免打开数据库的后门。导致这种后门常见的且易被遗忘的要素是遗留到生产环境中调试代码。

　　开发人员将后门放到程序中，其目的是为了调试，从而可以直接启用数据库的查询。忘记在生产环境中清除这种调试代码是愚蠢的，但也是很常见的错误。

　　7、劣质加密

　　比不使用加密更为糟糕的问题是，错误地使用加密，因为这这种加密给企业一种虚假的安全感。

　　问题存在于细节中，不管是一个哈希函数或是一个加密例程。如果你并不知道如何正确地实施加密，那将任务委托给一位专家，并且不要过早地将应用程序投放到生产环境中。

　　开发人员应当谨慎地对待其加密技术方面的技能和技巧。当今的黑客喜欢本地的加密设计，因为这种设计通常很差劲。

　　本地的加密几乎不能给有经验的攻击者提供什么价值，并且会给企业带来一种虚假的安全感。

　　8、盲目相信第三方代码

　　使用第三方的代码可能为开发人员节约大量的时间，但是开发人员不能在测试代码问题上抄近路，以确保所复制的代码不会给应用程序带来易受攻击的代码。

　　开发人员需要理解，自己要为整个应用程序的威胁分析负责，而不仅仅为自己编写的代码负责。

　　同样地，如果开发者希望限制那些给数据库带来风险的漏洞数量，他们应当使用新的开发框架。

　　许多开发人员会使用WordPress、 Joomla或其它类型的应用程序框架，却没有用新的安全补丁保持其新。许多类似的电脑都易遭受攻击，应用程序也如此。

　　9、轻率地实施REST（表述性状态转移）架构

　　表述性状态转移（REST）架构可能是一个有用的范例，但太多的工具会直接从数据库生成REST接口，从而将接口与数据库的设计架构联结起来，并可以暴露攻击者能够利用的信息。开发人员应当为一系列抽象的应用程序的特定资源类型和资源的适当操作设计REST接口，而不是把接口直接设计到物理的数据表和非特殊操作。

　　10、随处乱放备份的数据库副本

　　许多开发人员常常被责怪没有在测试环境（在其中，开发者寻求测试其应用程序的可选方式）中使用动态数据。不幸的是，这些编码者的许多人会转向备份数据库。

　　网站可以很好地保护动态数据库，但是否同样保护好了自己的数据库备份呢？在备份中，一周前的数据可能和动态数据一样具有破坏力，开发者可能会使用备份来针对生产性数据测试其工作，所以开发环境必须小心地遵循生产环境中的安全标准。安全策略应当为数据的所有副本负责，而不仅仅是在线副本。