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

Question

哪个客户端或服务器端验证更好？

在我们的情况下，我们正在使用

• jQuery和MVC。
• 在View和Controller之间传递的JSON数据。

我做的很多验证都是在用户输入数据时验证数据。 例如，我使用keypress事件来防止文本框中的字母，设置最大字符数以及数字在一个范围内。

我想更好的问题是，在客户端进行服务器端验证有什么好处吗？

---

很棒的回答每个人。我们拥有的网站受密码保护，并且用户群较小（<50）。如果他们没有运行JavaScript，我们将发送忍者。但如果我们为每个人设计一个网站，我同意在双方进行验证。

Answer 1

正如其他人所说，你应该做到这两点。原因如下：

客户端

您希望首先在客户端验证输入，因为您可以向普通用户提供更好的反馈。例如，如果他们输入无效的电子邮件地址并移至下一个字段，则可以立即显示错误消息。这样，用户可以在提交表单

之前更正之前的每个字段。

如果您只在服务器上进行验证，则必须提交表单，收到错误消息，并尝试搜索问题。

（通过让服务器在填写用户原始输入的情况下重新呈现表单，可以缓解这种痛苦，但客户端验证仍然更快。）

服务器端

您希望在服务器端进行验证，因为您可以防范恶意用户，他们可以轻松绕过您的JavaScript并向服务器提交危险输入。

信任您的UI非常危险。 他们不仅可以滥用您的用户界面，而且可能根本不使用您的用户界面，甚至是浏览器。如果用户手动编辑URL，或运行自己的Javascript，或使用其他工具调整HTTP请求，该怎么办？如果他们从curl或脚本发送自定义HTTP请求，该怎么办？

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

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

服务器端验证对于兼容性也很重要 - 并非所有用户（即使他们使用的是浏览器）都会启用JavaScript。

附录 - 2016年12月

有一些验证表明甚至无法在服务器端应用程序代码中正确完成，并且在客户端代码中完全不可能，因为它们依赖于数据库的当前状态。例如，“其他人没有注册该用户名”，或“您评论的博客文章仍然存在”，或“没有现有预订与您请求的日期重叠”，或“您的帐户余额仍然足以支付该购买“。 只有数据库才能可靠地验证依赖于相关数据的数据。开发人员regularly screw this up，但PostgreSQL provides some good solutions。

Answer 2

是的，始终可以完全绕过客户端验证。您需要同时执行这两项工作，客户端提供更好的用户体验，并且服务器端确保您获得的输入实际上已经过验证，而不仅仅是客户端验证的。

Answer 3

我只想重复一遍，因为它非常重要：

  

始终在服务器上验证

并为用户响应添加JavaScript。

Answer 4

通过客户端验证进行服务器端验证的好处是可以绕过/操纵客户端验证：

• 最终用户可以关闭javascript
• 数据可以由甚至没有使用您网站的人直接发送到您的服务器，并设有自定义应用程序
• 您网页上的Javascript错误（由任意数量的内容引起）可能会导致部分（但不是全部）运行验证

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

Answer 5

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

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

Answer 6

好吧，我仍然有空间回答。

除了Rob和Nathan的答案之外，我还要补充说，客户端验证很重要。在网络表单上应用验证时，您必须遵循以下准则：

客户端

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

服务器端

1. 您不应该假设在客户端成功完成的验证是100％完美的。即使它服务的用户少于50个。你永远不知道你的哪个用户/员工变成了“邪恶”并做了一些有害的活动，因为你知道你没有适当的验证。
2. 即使在验证电子邮件地址，电话号码或检查某些有效输入方面它是完美的，它也可能包含非常有害的数据。无论是正确还是错误，都需要在服务器端进行过滤。
3. 如果绕过客户端验证，您的服务器端验证可以帮助您免受服务器端处理的任何潜在损害。最近，我们已经听过很多关于SQL注入和其他可能应用的技术的故事，以获得一些恶意的好处。

两种类型的验证在各自的范围内都起着重要作用，但最强大的是服务器端。如果您在一个时间点收到10k用户，那么您肯定会最终过滤到您的网络服务器的请求数量。如果您发现有一个错误，例如无效的电子邮件地址，那么他们会再次回复该表单并要求您的用户更正它，这肯定会占用您的服务器资源和带宽。所以你应用javascript验证更好。如果javascript被禁用，那么你的服务器端验证将会解决，我打赌只有少数用户可能会意外地禁用它，因为99.99％的网站使用javascript，并且默认情况下已经在所有现代浏览器中启用了它。

Answer 7

您可以执行服务器端验证并发回一个JSON对象，其中包含每个字段的验证结果，使客户端Javascript保持最小（仅显示结果），并且仍然具有用户友好的体验，而无需在客户端和客户端上重复服务器

Answer 8

客户端应使用HTML5 input types和pattern attributes进行基本验证，因为这些仅用于渐进增强以获得更好的用户体验（即使＆lt; IE9和safari不支持它们，但我们不依赖它们）。但主要验证应该在服务器端进行..

Answer 9

可以在运行时修改JavaScript。

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

两端都需要单独的验证逻辑，例如：

"required"客户端

上的

inputs个属性

field.length > 0服务器端。

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

Answer 10

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

2018年7月23日更新：以下链接无法访问：

您可以在此处找到一些相关信息 http://www.webexpertlabs.com/server-side-form-validation-using-regular-expression/

Answer 11

我遇到了一个有趣的链接，可以区分粗略，系统，随机错误。

Client-Side validation非常适合防止粗略和随机错误。通常是纹理和输入的最大长度。不要模仿服务器端验证规则;提供您自己的粗略经验法则验证规则（例如客户端的200个字符;服务器端的n由强大的业务规则决定）。

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

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

进一步阅读：粗略，系统，随机的错误：

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

Answer 12

客户端数据验证对于改善用户体验很有用：例如，我输入错误电子邮件地址的用户不应该等待，直到远程服务器处理了他的请求，以了解他的错字。< / p>

尽管如此，由于攻击者可以绕过客户端验证（甚至可能根本不使用浏览器），因此服务器端验证是必需的，并且必须是保护后端免受恶意用户攻击的真正大门。

Answer 13

如果您正在进行光验证，最好在客户端进行验证。它将节省网络流量，这将有助于您的服务器更好地执行。如果它复杂的验证涉及从数据库中提取数据或某些东西，如密码，那么最好在可以安全检查数据的服务器上进行。