为什么我们需要服务器端以及Web应用程序的客户端验证？

Question

是否有任何高级别的理由同时为Web应用程序进行客户端和服务器端验证？

Answer 1

因为您的客户端验证可能会被破坏。

例如 - 在网络上，如果您使用javascript进行验证，则可以轻松关闭javascript，或使用FireBug等工具更改其工作方式。

使用其他客户端/服务器方法的事件，可能会破坏数据链接，并且可以在前往服务器的途中更改“已验证”的数据（Man In The Middle攻击）。

一般而言，“永不信任客户”的格言是您需要始终在服务器上进行验证的原因。

在这种情况下，您可能会问，为什么要在客户端验证？为了提供即时反馈。

Answer 2

用户可以在本地修改验证JavaScript（保存页面并使用它做任何事情）或者可以在浏览器中关闭javascript。因此，在这种情况下，客户端验证是无用的。因此，您应该在服务器上验证

Answer 3

客户端验证为用户提供即时反馈，而无需等待页面加载。但是，如果客户端已禁用客户端脚本（例如禁用了JavaScript），则验证将不会触发，这也是您需要服务器检查值的原因。

Answer 4

客户端将在到达服务器之前删除（理论上）大多数验证问题（尽管在禁用/编辑JavaScript时并非总是如此）。这将通过将责任放在客户端设备上以执行验证来从服务器中删除任何“紧张”/不必要的处理。

服务器端将捕获由于某种原因未被客户端验证捕获的任何验证问题。

Answer 5

客户端验证是一个优点，但不是必需的。您必须使用服务器端验证（ssv），因为当您接受用户信息时，您应始终将其视为“敌对”。如果该数据也被送入数据库，则ssv是您的最后一道防线，因为您不需要数据库中的垃圾或无效数据。

客户端验证不是防弹，因此如果在客户端验证某些内容，这并不意味着它在到达您的服务器时有效。

Answer 6

客户端验证用于以下
1）数据到长度和格式约束的构造
2）即时指示或反馈给用户

服务器端验证
1）针对业务逻辑的更高级验证
2）检查标准的任何变化。例如，您从亚马逊订购一本书，在您结账时，您会看到该书已缺货，因为其他人会在此之前就购买该书 3）检查目标用户是否已发布数据。客户端的东西，如cookie和javascript可以被操纵，因此服务器确实需要验证和污染检查通过的数据。

因此，需要服务器端验证作为防御恶意数据的主要防线，并且还需要根据高级业务逻辑检查数据。

Answer 7

实时客户端验证的目的（即，当用户从一个字段移动到另一个字段而不是在用户点击SUBMIT之后）是尽快给用户提供反馈。例如，如果社会安全号码需要9个数字，并且用户键入了8，您不希望等到用户完成表单的其余部分并点击SUBMIT指出错误，即使验证发生在客户端。等到SUBMIT验证客户端之后几乎毫无意义 - 所有这一切都是为了节省服务器和带宽。指出错误通常会导致更高的表单完成率，因为它对用户来说总体上更简单 - 不会出现错误列表：“请更正所有错误以下错误“。但是，您仍需要进行服务器端验证，以确保数据完整性。夜总会保镖站在俱乐部门前，而不是在街对面的停车场。

Answer 8

如果您的应用程序在数据库中有多个表，那么您的服务器端验证可能只是一组限制（数据表设计的一部分）。 我们可能认为我们在服务器端没有任何验证，因为它不是中间服务器层，而是数据库层限制。

然后我们可以说，利用关系数据库 - 基于Integrity（我们知道我们的数据结构是安全的）。在大多数情况下，我们可能仅使用客户端验证来向客户端提供对其操作的实例反馈。在服务器端层，在任何服务器端代码的控制器中进行额外验证可能不是一个关键问题。

因此，我们可以说，对于某些/大多数情况，我们可能只使用客户端验证。 服务器端验证是 - 特殊情况，例如：在客户提交购买表单时检查是否已经购买了某些东西。

不要重复双方的验证，这不是一个坏主意。

当然，有些应用程序需要对其数据进行大量关注，因此不仅服务器端验证很重要（例如业务模型安全的一部分，而且大多数用例的测试覆盖率 - 用于客户端的输入。

但如果它只是一个有多种形式的网站......那么我相信数据库限制和客户端验证是不错的选择。