在应用程序本身中，有两种输入验证方法可以防御 SQL 注入攻击：黑名单和白名单。
通过黑名单，可以从用户输入中删除或替换特定的已知恶意字符。尽管这种方法经常被实施，主要是因为它很容易实现，但与白名单相比，它并不有效。黑名单可能无法正确处理复杂的混淆，这可能允许攻击者破坏过滤器并可能注入 SQL 语句。这种失败通常是由于不断发展的攻击技术和过滤器不全面或未正确实施而导致的。
或者，白名单根据允许的字符列表检查每条用户输入。这种方法可以更有效地降低 SQL 注入的风险，因为它对允许的输入类型有更多的限制。实施良好的白名单应根据预期的数据格式检查用户提供的每条数据。
无论采用哪种方法，很可能都需要根据输入字段类型或输入字段类别（例如文本或数字数据）来定制允许的字符。用于过滤 SQL 注入启用字符的输入验证和清理功能可能会被泛化并用于过滤表明跨站点脚本攻击的字符。有关跨站点脚本的更多信息，请参阅应用智能白皮书 了解跨站点脚本 (XSS) 威胁向量。
当应用程序从用户接收到无效字符时，它必须确定性地采取行动。根据处理意外数据的情况及其可能产生的影响，不同级别的响应可能是适当的。例如，应用程序应明确拒绝提交两个破折号字符 (--) 或分号字符 (;) 作为登录名或密码一部分的用户，并且应向应用程序管理员发送高严重性警报。然而，当应用程序收到单个撇号字符作为由输入包裹运输信息的经过身份验证的用户提交的街道地址的一部分时，这种有点严厉的响应可能不合适。尽管如此，应用程序应该按预期运行，
输入验证和清理的实现应包含警报功能。当收到意外输入时，此功能应向应用程序管理或开发团队发出警报，因为它可能表明过滤器可能错误地阻止了有效但意外的数据，或者应用程序可能受到攻击。无论哪种情况，都可能需要更改应用程序的过滤功能。
乍一看，这些数据验证和清理技术似乎可以在客户端 JavaScript 中实现，并在用户的浏览器中运行。然而，从安全角度来看，必须假设任何和所有类型的数据都将源自用户的浏览器，无论客户端施加的保护措施如何。尽管如此，客户端数据验证技术可以增强应用程序的可用性
