Javascript 为什么我们需要客户端和服务器端验证？

使用验证器同时使用客户端验证（JavaScript）和服务器端验证的理由如下：如果客户端浏览器不支持JavaScript，则用户无法使用客户端验证。

---

我的问题是这个论点在实践中有多好？从理论上讲，这是有道理的，但在实践中，如果浏览器中禁用JavaScript，那么大多数网站功能甚至无法工作。用户甚至可能无法在没有JavaScript的情况下加载页面，更不用说提交表单了。

客户端验证只是避免客户端去“但是我填写了所有内容，它没有告诉我任何事情！”。实际上，它不是强制性的，实际上，客户端验证是一件非常新的事情（阅读：5年或更短）。实际上，它所做的只是防止客户端（启用了JS）在重新加载页面之前知道表单是否正常。 如果游戏中有AJAX，那就不同了——它允许您节省带宽，并在提交之前向用户提供反馈。 最后，如果您正在构建严格的客户端对等交换应用程序（想想游戏），那么您需要客户端验证来防止客户端作弊

服务器端验证也很重要，因为关闭JavaScript可以完全绕过客户端验证。在某种程度上，JS驱动的验证是一种方便和美观/美观的改进，不应依赖于此。此外，在本地编辑页面源代码以禁用或绕过最复杂的JS验证也很简单

---

如果不进行服务器端验证，用户可以做什么？任何事情，取决于你如何使用他们的数据。你可以允许用户删除整个数据库（或者更糟，泄露它们），修改他们喜欢的任何东西（或者更糟，读取他们喜欢的任何东西）。目录遍历缺陷是淘气的人极为常见的入口点，并且可以随意提升他们的权限。你想冒这个险吗？不验证用户输入就像信任他人而不在家中安装锁一样。

验证应始终在服务器端执行-您永远不能信任客户端验证

---

客户端验证总是为了提供更好的用户体验（UX），因此用户不必仅仅因为表单中的值无效而提交和重新加载页面—它使事情变得更加动态

由于您甚至不需要浏览器来发出请求，独立于依赖JS正常工作的网站，您将需要服务器端验证并清理所有用户输入，以防您担心数据库未被处理

---

现在，您可以决定是否要为UI提供动态客户端验证提示。

客户端验证是具有动态验证的高度交互式表单的解决方案，但它不会阻止恶意用户向服务器注入和发布无效的格式化数据。服务器端脚本必须验证用户正在执行的所有操作，否则您的站点将面临SQL注入攻击、XSS攻击、用户不应该执行的操作等。

始终保护您在服务器上的输入。这并不总是关于用户禁用JavaScript，而是他们可能会破坏服务器

例如，如果站点在

上有JavaScript最大长度检查，则用户可以禁用该检查，从而发送比服务器和/或数据库预期的更多的数据。这可能会导致服务器过载，因为大量的POST会占用服务器线程很长时间，这可能会暴露数据库中的弱点，例如违反数据库约束，从而可能暴露有关任何持久性信息的详细信息。更糟糕的是，如果没有约束，用户可能会执行注入攻击

另一个例子是有人使用外部HTTP工具向您的服务器发送请求，完全绕过任何JavaScript。我在开发过程中一直使用for Chrome来测试JSON API

---

通过JavaScript进行客户端验证只是一种向使用站点的人提供有关他们与站点交互的任何信息的快速反馈的方法。在传统的客户机-服务器通信中，出于上述原因，它不应该是唯一的验证。

如果用户禁用了javascript是他自己的问题，他决定单独禁用javascript是有原因的。。。为此，当你创建一个网站时，你必须始终牢记，你的网站必须对使用和不使用javascript的用户有效。需要进行双边验证的原因有很多，其中一些是：

• 用户已禁用javascript
• 一个恶意用户故意删除了javascript以利用系统进行攻击
• 通过javascript验证，您可以减少网站和客户端之间的数据流量
• 当然，通过服务器验证，您可以一次性确保数据是正确的

---

有可能有一个同时使用javascript和“旧”技术的网站对每个用户和每个浏览器都有效。

这可能更适合用户。投票迁移。还有潜在的重复：本质上，如果将客户端验证视为一个安全问题，则不存在这样的事情。不关闭JavaScript的浏览器可能会杀死互联网上95%的网站。几乎没有一个网站似乎有非javascript浏览的退路。@Allendar:大型网站有。如果你知道没有JS，Facebook（好吧，Facebook的大部分，有些是不可用的）就可以正常工作，你会感到惊讶。这是一个中端的“omg web2.0非常棒”网站，它不。。。这对他们和其他人来说都是一种耻辱。然而，有些人永远也学不到：-（看看这个。@Kaushik嗯，我通常在针对SQL注入测试页面时使用，我也使用No