logo标签列表

为什么Web应用程序需要服务器端和客户端验证？

validationserver-sideclient-side-validation
7

对于一个Web应用程序，同时在客户端和服务器端进行验证有什么高级别的原因吗？

8个回答
11

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

例如，在网络上，如果你使用JavaScript进行验证，很容易关闭JavaScript，或者使用诸如FireBug之类的工具更改它的工作方式。

即使使用其他客户端/服务器方法，数据链路也可能被破坏，并且“已验证”的数据在传输到服务器时可能会被更改（中间人攻击）。

总的来说，“永远不要相信客户端”这个原则是你需要始终在服务器端进行验证的原因。

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

3

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

那么客户端验证更多地是为了用户的利益，引导他们朝着正确的方向前进，而服务器端验证更多地是为了数据保护？ - eaglei22
3
客户端验证用于以下情况：
1）确认数据符合长度和格式限制
2）向用户提供即时指示或反馈
服务器端验证
1）对业务逻辑进行更高级别的验证
2）检查标准是否有任何更改。例如，您在亚马逊订购一本书，在结账后会收到一个指示，因为就在此时有人已经购买了这本书而缺货。
3）检查是否有意图的用户发布数据。客户端内容（如Cookie和JavaScript）可以被操纵，因此服务器需要对通过的数据进行身份验证和污点检查。
因此，服务器端验证是防止恶意数据并根据高级业务逻辑检查数据所必需的主要防线。
2
客户端验证可以在页面加载之前立即向用户提供反馈。然而，如果客户端禁用了客户端脚本（例如JavaScript被禁用），则验证不会触发，这就是为什么你需要服务器也要检查值的原因。
当使用Ajax时呢？在这种情况下，是仅依赖于从服务器返回的信息更好，还是开发人员仍然会使用Javascript / JQuery来防止不必要的ajax调用？或者只要服务器端被验证，那么它真的无关紧要吗？ - eaglei22
2

理论上，客户端将会在到达服务器之前移除大部分验证问题（尽管当 JavaScript 被禁用/编辑时并不总是如此）。这将通过将责任放在客户端设备上执行验证来消除服务器上的任何“负担”/不必要的处理。

如果由于某种原因客户端未能捕获验证问题，服务器端将会捕获它们。

2
客户端验证是优点，但不是必需的。你必须使用服务器端验证（ssv），因为当你接受用户信息时，应该始终将其视为“敌对”的。如果这些数据也被输入到数据库中，ssv是你的最后一道防线，因为你不希望在数据库中出现垃圾或无效数据。
客户端验证并不是万无一失的，因此如果某些内容在客户端得到验证，这并不意味着它在到达服务器时就是有效的。
2
实时客户端验证（即用户在填写表单时，移动到下一个字段时进行验证而不是提交表单后才进行验证）的目的是尽快向用户提供反馈。例如，如果社会安全号码需要9位数字，而用户只输入了8位数字，即使在客户端进行验证，也不要等到用户完成表单并提交后再指出错误。在提交后再进行客户端验证几乎没有意义，它只是为了节省服务器和带宽资源。及时指出错误通常会导致更高的表单完成率，因为这对用户来说是更简单的体验——不会有错误列表：“请纠正以下所有错误”。但无论如何，您仍需要进行服务器端验证以确保数据完整性。夜店保镖站在夜店门口，而不是停车场对面。
0
如果您的应用程序在数据库中有多个表格，那么您的服务器端验证可能只是一组限制（数据表设计的一部分）。我们可能认为我们没有任何服务器端验证，因为它不是中间服务器层，而是DB层限制。
然后我们可以说，利用关系型数据库的优势-基于完整性（我们知道我们的数据结构是安全的）。在大多数情况下，我们可以仅使用客户端验证来为客户提供实例反馈以响应他的操作。在控制器或任何服务器端代码中，没有额外的验证可能不是一个关键问题。
因此，我们可以说，在某些/大多数情况下，我们可以仅使用客户端验证。服务器端验证是-特殊情况，例如：当客户提交购买表单时，检查是否已经购买了某些东西。
不重复自己在两侧进行验证并不是坏主意。
当然，有些应用程序需要对其数据进行大量关注，因此不仅服务器端验证很重要（如业务模型安全的一部分），而且还需要测试覆盖大多数用例-针对客户输入。
但是，如果只是一个带有几个表单的网站...那么我相信数据库限制和客户端验证是一个不错的选择。
网页内容由stack overflow 提供, 点击上面的
可以查看英文原文，
原文链接