数据输入验证对我来说一直是内部的斗争。
即将在我们的旧应用程序重写项目中添加一个真正的安全框架和代码（到目前为止，该框架几乎保持了卡式城堡般的旧安全代码和数据验证），我再次想知道应该验证多少，哪里等等
在担任Java专业开发人员的5年中，我创建并完善了个人规则，以进行数据输入验证和安全措施。当我想改进自己的方法时，我希望有人听到你们的一些想法。通用规则和过程很好，并且特定于Java的规则和过程也很好。
归纳起来，以下是我的指南（在3层Web应用程序样式中公开），并带有简要说明：
第一层客户端（浏览器）：最低限度的验证，只有不变的规则（必填电子邮件字段，必须选择一项，依此类推）；减少使用诸如“ 6到20个字符之间”之类的附加验证的频率，因为这会增加对变更的维护工作（可以在业务代码稳定后添加）；
第一层服务器端（网络通信处理，“控制器”）：我对此没有规定，但我认为此处仅应处理数据处理和组装/解析错误（生日字段不是有效日期）；在此处添加进一步的验证很容易使其变得很无聊。
第二层（业务层）：可靠的验证，不少于；输入数据格式，范围，值，内部状态检查（是否可以随时调用方法），用户角色/权限等；使用尽可能少的用户输入数据，如果需要，再次从数据库中检索它；如果我们也将检索到的数据库数据也视为输入，则只有在已知某些特定数据在DB上不可靠或已损坏得足够多的情况下，我才会对其进行验证-强类型化在这里做了大部分工作，恕我直言；
第三层（数据层/ DAL / DAO）：从来没有认为这里需要太多的验证，因为只有业务层才可以访问数据（在某些情况下，例如“ param1为true时，param2不能为空”验证）；但是请注意，当我的意思是“这里”是指“访问数据库的代码”或“ SQL执行方法”时，数据库本身是完全相反的；
数据库（数据模型）：需要充分考虑，强大和自我实施，以尽可能避免DB上的数据不正确和损坏，并具有良好的主键，外键，约束，数据类型/长度/大小/ precision等-我不再赘述，因为他们有自己的私人讨论。
我知道早期的数据验证是不错的并且是性能方面的，但是重复的数据验证是一个无聊的过程，并且我承认数据验证本身很烦人。这就是为什么这么多编码员跳过它或半途而废的原因。同样，如果每个重复的验证并非始终保持同步，则可能是一个错误。这些是当今我更喜欢将大多数验证放到业务层的主要原因，但要浪费时间，带宽和CPU，并要逐案处理异常。
所以，对于这个你有什么想法？反对意见？您还有其他程序吗？提到这样的话题？任何贡献均有效。
注意：如果您正在考虑Java的做事方式，我们的应用程序是基于Spring的Spring MVC和MyBatis（性能和不良的数据库模型排除了ORM解决方案）；我计划将Spring Security添加为我们的安全提供程序以及JSR 303（休眠验证器？）。
谢谢！
编辑：在第三层的一些额外的澄清。