1.应用中不可直接使用日志系统(Log4j、Logback)中的API,而应依赖使用日志框架SLF4J中的API,使用门面模式的日志框架,有利于维护和各个类的日志处理方式统一
2.日志文件推荐至少保存15天,因为有些异常具备以‘周’为频次发生的特点
3.应用中的扩展日志命名方式以:appName_logType_logName.log,好处是日志日志文件属于什么应用,什么类型,什么目的,有利于归类查找;方便错误日志和业务日志查找。
logType(推荐 status/desc/monitor/visit等)
4.日志输出级别trace/debug/info等 必须使用条件输出形式或者使用占位符的方式,避免直接使用字符串拼接操作
(条件) if(logger.isDebugEnabled()){
logger.debug("the log id is "+id+"date is :"+date);
}
(占位符) logger.debug("the log id is {} and date is {} ",id,date);
5.避免重复打印日志,浪费磁盘空间,务必在log4j.xml中设置additivity=false
6.异常信息应该包括两类信息:案发现场信息;异常堆栈信息
如: logger.error("the id {}and date{} is ", id, date + "_", e.getMessage(), e); 如果不处理,使用关键字throws往上抛
7.warn日志级别记录用户输入参数错误的情况,error级别只记录系统逻辑错误、异常等重要的错误信息
谨慎地记录日志。生产环境禁止输出debug日志;有选择的输出info日志,注意warn日志记录刚上线业务行为信息的数量。
8.隶属于用户个人的页面或者功能必须进行权限控制检验
9.用户敏感数据禁止直接展示
10.用户输入的SQL参数严格使用参数绑定或者METADATA字段值限制,防止SQL注入,禁止字符串拼接SQL访问数据库
11.用户请求传入的任何参数必须做有效性验证。 说明:忽略参数校验可能导致:
page size过大导致内存溢出;恶意order by 导致数据库慢查询;任意重定向;SQL注入;反序列化注入正则输入源串拒绝服务ReDos
12.禁止向 HTML 页面输出未经安全过滤或未正确转义的用户数据。表单、AJAX 交必须执行 CSRF 安全过滤 CSRF(Cross-site request forgery)跨站请求伪造是一类常见编程漏洞。对于存在 CSRF 漏洞的应用/网站,攻击者可以事先构造好 URL,只要受害者用户一访问,后台便在用户 不知情情况下对数据库中用户参数进行相应修改。
13,在使用平台资源,譬如短信、邮件、电话、下单、支付,必须实现正确的防重放限制, 如数量限制、疲劳度控制、验证码校验,避免被滥刷、资损。
14.发贴、评论、发送即时消息等用户生成内容的场景必须实现防刷、文本内容违禁词过 滤等风控策略。