开发时验证的前后台验证

正常来说，前台验证和后台验证是都要有的。

因为JS验证不安全，如果有意为之，那么完全可以绕过你的JS验证。

如果你开发的是商业应用，那么稳定性和安全性是相当重要的，而这里就存在有安全漏洞。

客户端验证：仅仅是为了方便，它可以为用户提供快速反馈，给人一种运行在桌面应用程序的感觉，使用户能够及时察觉所填写数据的不合法性。基本上用脚本代码实现，如JAVASCRIPT或VBSCRIPT，不用把这一过程交到远程服务器。如果所有验证都要通过请求服务器，服务器压力太大了，没有必要的事儿。

服务器端验证：构建安全Web应用程序所必需的，不管在客户端一侧输入的是什么，它可以确保客户端送往服务器最后处理的所有数据都是有效的，以免出现一些漏洞或者不应该的异常。

比如说一个注册页面，填好注册信息后，你点击提交按钮，那么它没有跳转就提示你填写有误，这一过程一般很快，返回时页面也不晃动，但如果用服务器端验证，你填好后，可能会跳到另一页面，返回得很慢，中间有可能有一段空白时段，返回后页面出现重写或晃动返回。客户端验证在提交到服务器动态处理页面前可以不用动态语言，而服务器端验证实际上是把信息提交到服务器上的动态页面里才实现验证。

从这个方面可以得知，客户端验证比较快些，可以实现本地机验证，减少用户的等待时间，如果提交到服务器端验证，用户到最后等了几分钟才返回注册不正确的提示，那岂不是让用户十分懊恼？所以，客户端验证又是比较友好的。但服务器端的验证更安全一些，因为代码在客户端是看不到的，而客户端验证的代码是可以从网页的查看“源文件”HTML页一清二楚的。

认为只在客户端验证就足够的观点，是建立在若干假设条件基础上的。如：假设所有的Web应用程序用户都同样诚实，假设所有用户将总是使用他们测试过的浏览器访问Web应用程序，还有很多其他假设。然而，这样的假设对于一个蓄意破坏者来说，无疑是一个搞破坏的极佳入手点。

事实上，通过在浏览器窗口中键入适当的URL，您可以发送任何"posted"表单，尽管可以通过禁用这些页面的GET请求很容易阻止这样的“表单”发送，但是却不能阻止用户通过模拟一个表单提交数据来入侵你的系统。
拿用户注册表单来说，用户在获得注册表单后，可以查看其HTML源代码，并且将其保存下来，将其中的JavaScript代码去掉，另存为一个本地HTML文件，再在本地运行，填写数据，同样可以成功达到向服务器提交不合理数据的目的。

总结：

“客户端验证给用户带来方便，其存在的原因主要是对用户考虑，但是它不能保证安全性，用户可以轻易绕过。因此，对于一个安全的数据验证方案，服务器端的验证是必须的，在设计应用系统时，必须考虑到这个要求。