将导致服务器被者拿下，而代码注入（包括SQL，LDAP，操作系统命令，XPath注入技术）长年保持在OWASP漏洞排名前十。
更多人分享有关于应用安全的知识是一件极好的事。然而不幸的是，网络上流传的大部分东西（尤其是老博客文章,高搜索引擎排名）都已经过时了。虽然是无意的，但是却造成了很大的。
在PHP应用中预处理语句过滤掉任何SQL注入的可能，无论是什么都需要先传递到$_GET变量。SQL查询语句是者无法改变的（除非你将PDO::ATTR_EMULATE_PREPARES 了，这也意味着你还没有真正使用预处理语句）
预处理语句解决应用安全的根本问题：通过发送完全的包将操作指令与数据进行单独处理。这和导致堆栈溢出的问题有点类似了。
只要你没有用SQL语句连接user-provided变量和变量（并且你没有使用emulated prepares），那你就不必担心交叉SQL注入的问题了。
预处理语句确保WEB应用与数据库服务之间的交互（即使两者不在同一台机器上，也会通过TLS进行连接）。者还有可能在字段中存储一个payload，这是相当的，比如一个存储过程，我们称之为高阶SQL注入。
在这种情况下，我们不要编写存储过程，它会制造一个高阶SQL注入点。
应该有人看到过这张关于SQL注入的漫画吧，在一些安全会议上甚至都经常被拿来引用，尤其是写给新人的文章中。这张漫画提醒了我们要提高对数据库查询中用户输入的意识，但是漫画中的却是过滤掉数据库输入，通过对相关问题的理解，我们知道这仅仅是一个折衷的办法。
虽然可以在数据发送到数据库之前重写传入的数据流来防止者的，但是这个过程比较难以把控。
除非你想花时间去研究，达到完全掌握所有Unicode格式应用程序，你最好不要尝试过滤你的输入。
此外，改变你的输入数据流可能造成数据损坏。特别是在你正在处理原始二进制文件（图片，加密信息）的时候。
当列和表标识符作为查询语句中的一部分，你不能使用参数表示它们。如果你正在开发的这个应用需要一个动态查询结构，请使用白名单。
白名单是一个应用程序逻辑策略，它只允许少数可信的值。相对来说，仅仅是已知的恶意输入。
大多数情况下，使用白名单比更安全！
=;([]) {:::.=.[];(!([])) {.=;}{.=;}:.=;}=-prepare();(-execute([[]])) {=-fetchAll(\PDO::FETCH_ASSOC); }
开发者第一次遇到预处理语句，对于需要写大量的冗余代码而感到沮丧（提取，执行，取回；提取，执行，取回；.令人厌烦）
由此，EasyDB[诞生了。