注意：动态构建一个查询的存储过程是可以做到的：这么做无法防止SQL注入 – 它只不过把预编译/执行绑定到了一起，或者是把SQL语句和提供保护的变量绑定到了一起。
隔离web服务器实施了以上所有的防御措施，仍然可能有某些地方有遗漏，导致了服务器被渗透。设计者应该在假定坏蛋已经获得了系统最高权限下来设计网络设施，然后把它的攻击对其他事情产生的影响限制在最小。
例如，把这台机器放置在极度限制出入的DMZ网络“内部”，这么做意味着即便取得了web服务器的完全控制也不能自动的获得对其他一切的完全访问权限。当然，这么做不能阻止所有的入侵，不过它可以使入侵变的非常困难。
配置错误报告一些框架的错误报告包含了开发的bug信息，这不应该公开给用户。想象一下：如果完整的查询被现实出来了，并且指出了语法错误点，那要攻击该有多容易。
对于开发者来说这些信息是有用的，但是它应该禁止公开 – 如果可能 – 应该限制在内部用户访问。
注意：不是所有的数据库都采用同样的方式配置，并且不是所有的数据库都支持同样的SQL语法（“S”代表“结构化”，不是“标准的”）。例如，大多数版本的MySQL都不支持子查询，而且通常也不允许单行多条语句（multiple statements）：当你渗透网络时，实际上这些就是使问题复杂化的因素。
再强调一下，尽管我们选择了“忘记密码”链接来试试攻击，但不是因为这个功能不安全。而是几个易攻击的点之一，不要把焦点聚集在“忘记密码”上。
这个教学示例不准备全面覆盖SQL注入的内容，甚至都不是一个教程：它仅仅是一篇我们花了几小时做的渗透测试的记录。我们看了其他的关于SQL注入文章的讨论，但它们只给出了结果而没有给出过程。
但是那些结果报告需要技术背景才能看懂，并且渗透细节也是有价值的。在没有源代码的情况下，渗透人员的黑盒测试能力也是有价值的。