答案 0 :(得分：60)
客户端验证 - 我假设您在这里讨论网页 - 依赖于JavaScript。
JavaScript驱动的验证可以在用户的浏览器中关闭，由于脚本错误而失败，或者在不费力的情况下被恶意规避。
此外，表单提交的整个过程可以伪造。
因此，从来没有保证到达服务器端，是干净安全的数据。
答案 1 :(得分：18)
编写服务器应用程序时有一条简单的规则：绝不信任用户数据。
您需要始终假设恶意用户以您不想要的方式访问您的服务器（例如，通过curl通过手动查询而不是预期的网页）。例如，如果您的网页试图过滤掉SQL命令，则攻击者已经很好地提示它可能是一个很好的攻击向量来传递带有SQL命令的输入。
答案 2 :(得分：12)
任何知道基本javascript的人都可以绕过客户端。
客户端用于改善用户体验（无需重新加载页面进行验证）
答案 3 :(得分：7)
您正在与之交谈的客户可能不是您正在与之交谈的客户，因此可能无视您要求它做的任何验证。
在网络环境中，用户不仅可能在浏览器中禁用了javascript，而且还有可能根本就没有与浏览器通话 - 您可能会从机器人获取表单提交这是在没有看过表格的情况下发布到你的提交网址。
在更广泛的背景下，您可能正在处理一个黑客客户端，该客户端正在发送真实客户端永远不会发送的数据（例如，FPS游戏的目标机器人），甚至可能是由反向工程的人创建的完全自定义客户端您的有线协议，它对您期望执行的任何验证一无所知。
答案 4 :(得分：6)
不是特定于Javascript和Web客户端并且更广泛地解决问题，服务器应该负责维护自己的数据（与底层数据库一起）。
在客户端 - 服务器环境中，服务器应该准备好了许多不同的客户端实现可以与之通信的事实。考虑一个贸易准入制度。客户端可以是GUI（例如交易输入系统）和（比如）数据上载客户端（从.csv文件加载多个交易）。
客户端验证可能以多种不同的方式执行，而不是全部正确。因此，服务器不一定信任客户端数据并自行执行完整性检查和验证。
答案 5 :(得分：5)
如果攻击者发布自己的表单。
答案 6 :(得分：3)
您可以关闭/编辑JavaScript。
答案 7 :(得分：3)
因为用户代理（例如浏览器）可能是虚假的。创建自定义应用程序以创建具有任意标头和内容的HTTP请求非常容易。它甚至可以说它是一个真正的浏览器 - 你无法区分它们。
您所能做的只是查看请求的内容，如果您不检查它，则不知道它是否有效。
答案 8 :(得分：1)
服务器端验证是必须的，因为客户端验证不能确保未经验证的数据将到达服务器。
客户端验证是不够的，因为它的操作范围非常有限。验证仅在浏览器用户界面中执行。
网络服务器“侦听”并接收包含浏览器数据的 HTTP请求，然后对其进行处理。
恶意用户可以通过多种方式发送恶意HTTP请求。甚至不需要浏览器。
在浏览器中使用JavaScript执行的客户端验证是一项重要的可用性，用户界面增强功能。但不会阻止用户知道如何绕过构建将发送到服务器的HTTP请求的浏览器默认行为来发送恶意数据。这可以通过一些浏览器插件轻松完成，使用cURL等。
答案 9 :(得分：1)
一般来说，每个应用程序最好自己进行检查/验证。
客户端检查有助于最大限度地提高用户体验并加快对客户端的反馈，以及他们需要修复的内容，并减少服务器端检查中遇到的问题。
然后，在服务器端代码的每个主要转换点上，您都应该在那里进行检查。验证应用程序代码中的输入，最好通过whitelist input validation，然后与数据库进行任何交互，使用参数化查询，以进一步确保不会出现问题。
答案 10 :(得分：0)
您应该对任何数据执行服务器端验证，如果这些数据无效，可能会对发布数据的实体以外的任何人造成损害。客户端验证可能适用于无效数据对发布它的实体以外的任何人都没有不良影响的情况。除非您可以确定不良数据的不良影响不会超出发布它的实体，否则您应该使用服务器端验证来保护自己免受破坏者或其他恶意客户的攻击。</ p>
答案 11 :(得分：0)
客户端验证用于保存客户端不输入错误数据。服务器端验证用于保存服务器以处理错误数据。在此过程中，它还在提交过程中引入了一些安全性。
答案 12 :(得分：0)
客户端验证以安全浏览器，客户端语言或HTML 5为前提。所有这些元素都可能被禁用，部分无法使用或根本无法实现。每个浏览器都必须使用您的网站。 服务器端语言更安全，如果它们不是错误 - 验证肯定会更安全和正确。
答案 13 :(得分：0)
Buddy，假设一个人在浏览器中关闭javascript，验证就会失效。然后，如果他通过该表单将一些有意义的内容发布到服务器端。它将导致严重的漏洞，如SQL注入或xss或任何其他类型的问题。因此，请注意您是否要实现客户端javascript验证。
谢谢