JavaScript:客户端验证与服务器端验证

是的，总是可以完全绕过客户端验证。您需要做到这两点:客户端提供更好的用户体验，服务器端确保您得到的输入是实际验证的，而不仅仅是客户端假定的验证。

如果您正在进行轻量级验证，最好在客户端上进行。它将节省网络流量，这将帮助您的服务器更好地运行。如果验证很复杂，需要从数据库中提取数据或密码之类的东西，那么最好在可以安全地检查数据的服务器上进行验证。

做服务器端验证而不是客户端验证的好处是客户端验证可以被绕过/操纵:

• 最终用户可以关闭javascript
• 数据可以通过一个定制的应用程序直接发送到你的服务器，而这个人甚至不使用你的网站
• 页面上的Javascript错误(由各种原因引起)可能导致部分(而不是全部)验证运行

简而言之，始终始终验证服务器端，然后将客户端验证视为增强最终用户体验的“额外”。

您必须始终在服务器上验证。

在客户端上进行验证对用户来说也很好，但这是完全不安全的。

我再重复一遍，因为这很重要:

始终在服务器上验证

并添加JavaScript用于用户响应。

正如其他人所说，你应该两者兼顾。原因如下:

客户端

你想先在客户端验证输入，因为你可以给出更好的反馈给普通用户。例如，如果他们输入了无效的电子邮件地址并移动到下一个字段，您可以立即显示错误消息。这样用户就可以纠正他们提交表单的每个字段。

如果您只在服务器上进行验证，则他们必须提交表单，获得错误消息，并尝试查找问题。

(这种痛苦可以通过让服务器重新呈现用户原始输入的表单来缓解，但客户端验证仍然更快。)

服务器端

你想要在服务器端验证，因为你可以防范恶意用户，它可以很容易地绕过你的JavaScript并向服务器提交危险的输入。

相信你的UI是非常危险的。他们不仅会滥用你的UI，还可能根本不使用你的UI，甚至根本不使用浏览器。如果用户手动编辑URL，或者运行他们自己的Javascript，或者使用其他工具调整他们的HTTP请求呢?例如，如果它们从curl或从脚本发送自定义HTTP请求呢?

(这不是理论上的;我在一个旅游搜索引擎上工作，它通过发送POST请求将用户的搜索重新提交给许多合作航空公司、公交公司等，就好像用户已经填写了每个公司的搜索表单，然后收集和排序所有的结果。这些公司的表单JS从未执行过，他们在返回的HTML中提供错误消息对我们来说至关重要。当然，API本来就很好，但这是我们必须要做的。)

从安全的角度来看，不允许这样做不仅是幼稚的，而且是不标准的:应该允许客户端以任何他们希望的方式发送HTTP，并且您应该正确地响应。这包括验证。

服务器端验证对于兼容性也很重要——不是所有用户，即使他们使用浏览器，也会启用JavaScript。

附录- 2016年12月

有一些验证甚至不能在服务器端应用程序代码中正确地完成，而在客户端代码中完全不可能，因为它们依赖于数据库的当前状态。例如，“没有其他人注册了这个用户名”，或者“你评论的博客文章仍然存在”，或者“现有的预订与你要求的日期没有重叠”，或者“你的账户余额仍然足够支付那次购买”。只有数据库才能可靠地验证依赖于相关数据的数据。开发者经常搞砸，但PostgreSQL提供了一些很好的解决方案。

好吧，我还是可以回答的。

除了Rob和Nathan的回答，我还想补充一点，客户端验证很重要。当你在你的web表单上应用验证时，你必须遵循以下准则:

客户端

1. 必须使用客户端验证，以过滤来自您网站的真实用户的真实请求。
2. 应该使用客户端验证来减少在服务器端处理期间可能发生的错误。
3. 应该使用客户端验证来最小化服务器端往返，从而节省带宽和每个用户的请求。

服务器端

1. 你不应该假设在客户端成功完成的验证是100%完美的。即使用户少于50人也没关系。你永远不知道你的哪个用户/员工会变成“坏人”。做一些有害的活动，知道你没有适当的验证。
2. 即使它在验证电子邮件地址、电话号码或检查一些有效输入方面很完美，但它可能包含非常有害的数据。无论它是正确的还是不正确的，都需要在服务器端进行过滤。
3. 如果绕过了客户端验证，则服务器端验证可以将您从对服务器端处理的任何潜在损害中拯救出来。最近，我们已经听到了很多关于SQL注入和其他类型的技术的故事，这些技术可能被用于获得一些邪恶的好处。

这两种类型的验证在各自的范围内都扮演着重要的角色，但最强大的是服务器端。如果你在一个时间点上接收了1万用户，那么你最终肯定会过滤到你的web服务器的请求数量。如果你发现有一个单一的错误，如无效的电子邮件地址，然后他们再次发布回表单，并要求你的用户更正它，这肯定会消耗你的服务器资源和带宽。所以最好还是应用javascript验证。如果javascript被禁用了，那么你的服务器端验证就会来拯救你，我打赌只有少数用户可能会不小心禁用它，因为99.99%的网站使用javascript，而且它在所有现代浏览器中已经默认启用。

您可以进行服务器端验证，并将每个字段的验证结果发送回一个JSON对象，将客户端Javascript保持在最低限度(只显示结果)，并且仍然具有用户友好的体验，而无需在客户端和服务器上重复。

客户端应该通过HTML5输入类型和模式属性使用基本验证，因为这些仅用于渐进增强以获得更好的用户体验(即使它们在<上不受支持;IE9和safari，但我们不依赖它们)。但是主要的验证应该发生在服务器端。

JavaScript可以在运行时修改。

我建议在服务器上创建验证结构，并与客户端共享该结构。

你需要在两端单独的验证逻辑，例如:

inputs客户端上的"required"属性

field.length > 0服务器端。

但是使用相同的验证规范将消除两端镜像验证的一些冗余(和错误)。

我将建议实现客户端和服务器验证，它使项目更安全......如果我必须选择一个，我会选择服务器端验证。

我遇到了一个有趣的链接，它区分了严重的、系统性的、随机的错误。

Client-Side validation适合于防止严重和随机错误。通常是任何输入的最大长度。不要模仿服务器端验证规则;提供你自己粗略的经验验证规则(例如客户端200个字符;由强业务规则指定的服务器端特定n字符小于200)。

Server-side validation适合于防止系统错误;它将执行业务规则。

在我参与的一个项目中，验证是通过ajax请求在服务器上完成的。在客户机上，我相应地显示错误消息。

进一步阅读:严重的、系统性的、随机的错误:

https://answers.yahoo.com/question/index?qid=20080918203131AAEt6GO

客户端数据验证对于更好的用户体验很有用:例如，如果用户输入了错误的电子邮件地址，就不应该等到远程服务器处理了他的请求后才知道他输入了错误。

然而，由于攻击者可以绕过客户端验证(甚至可能根本不使用浏览器)，所以服务器端验证是必需的，并且必须是保护后端免受恶意用户攻击的真正大门。