java开发规范(简洁版)

一、编程规约
(一)命名规约
1.【强制】所有编程相关命名均不能以下划线或美元符号开始,也不能以下划线或美元符号结束。
反例:_name/__name/$Object/name_/name$/Object$
2.【强制】所有编程相关的命名严禁使用拼音与英文混合的方式,更不允许直接使用中文的方式。
反例:DaZhePromotion [打折] / getPingfenByName() [评分] / int 变量 = 3;
正例:ali / alibaba / taobao / cainiao / aliyun / youku / hangzhou等国际通用的
名称,可视为英文。
3. 【强制】类名使用UpperCamelCase风格,必须遵从驼峰形式,但以下情形例外:(领域模型的相关命名)DO / DTO / VO / DAO等。
正例:MarcoPolo / UserDO / XmlService / TcpUdpDeal / TaPromotion
反例:macroPolo / UserDo / XMLService / TCPUDPDeal / TAPromotion
4. 【强制】方法名、参数名、成员变量、局部变量都统一使用lowerCamelCase风格,必须遵从驼峰形式。
正例:localValue / getHttpMessage() / inputUserId
5.【强制】常量命名全部大写,单词间用下划线隔开,力求语义表达完整清楚,不要嫌名字长。
正例:MAX_STOCK_COUNT
反例:MAX_COUNT
6. 【强制】抽象类命名使用Abstract或Base开头;异常类命名使用Exception结尾;测试类命名以它要测试的类的名称开始,以Test结尾。
7. 【强制】中括号是数组类型的一部分,数组定义如下:String[]args;
反例:请勿使用String args[]的方式来定义
8. 【强制】POJO类中的任何布尔类型的变量,都不要加is,否则部分框架解析会引起序列化错误。
反例:定义为基本数据类型boolean isSuccess;的属性,它的方法也是isSuccess(),RPC框架在反向解析的时候,“以为”对应的属性名称是success,导致属性获取不到,进而抛出异常。
9.【强制】包名统一使用小写,点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用单数形式,但是类名如果有复数含义,类名可以使用复数形式。
正例: 应用工具类包名为com.alibaba.mpp.util、类名为MessageUtils(此规则参考spring的框架结构)
10.【强制】杜绝完全不规范的缩写,避免望文不知义。
反例:<某业务代码>AbstractClass“缩写”命名成AbsClass;condition“缩写”命名成
condi,此类随意缩写严重降低了代码的可阅读性。
11.【推荐】如果使用到了设计模式,建议在类名中体现出具体模式。
说明:将设计模式体现在名字中,有利于阅读者快速理解架构设计思想。
正例:public class OrderFactory;
public class LoginProxy;
public class ResourceObserver;
12.【推荐】接口类中的方法和属性不要加任何修饰符号(public也不要加),保持代码的简洁性,并加上有效的javadoc注释。尽量不要在接口里定义变量,如果一定要定义变量,肯定是与接口方法相关,并且是整个应用的基础常量。
正例:接口方法签名:void f();
接口基础常量表示:String COMPANY = "alibaba";
反例:接口方法定义:public abstractvoid f();
13.接口和实现类的命名有两套规则:
1)【强制】对于Service和DAO类,基于SOA的理念,暴露出来的服务一定是接口,内部的实现类用Impl的后缀与接口区别。
正例:CacheServiceImpl实现CacheService接口。
2)【推荐】 如果是形容能力的接口名称,取对应的形容词做接口名(通常是–able的形式)。
正例:AbstractTranslator实现 Translatable。
14.【参考】枚举类名建议带上Enum后缀,枚举成员名称需要全大写,单词间用下划线隔开。
说明:枚举其实就是特殊的常量类,且构造方法被默认强制是私有。
正例:枚举名字:DealStatusEnum;成员名称:SUCCESS / UNKOWN_REASON。
15.【参考】各层命名规约:
A) Service/DAO层方法命名规约
1) 获取单个对象的方法用get做前缀。
2) 获取多个对象的方法用list做前缀。
3) 获取统计值的方法用count做前缀。
4) 插入的方法用save(推荐)或insert做前缀。
5) 删除的方法用remove(推荐)或delete做前缀。
6) 修改的方法用update做前缀。
B)领域模型命名规约
1) 数据对象:xxxDO,xxx即为数据表名。
2) 数据传输对象:xxxDTO,xxx为业务领域相关的名称。
3) 展示对象:xxxVO,xxx一般为网页名称。
4) POJO是DO/DTO/BO/VO的统称,禁止命名成xxxPOJO。
(二)常量定义
1.【强制】不允许出现任何魔法值(即未经定义的常量)直接出现在代码中。
反例:String key="Id#taobao_"+tradeId;
cache.put(key, value);
2. 【强制】long或者Long初始赋值时,必须使用大写的L,不能是小写的l,小写容易跟数字1混淆,造成误解。
(三)格式规约
1. 【强制】大括号的使用约定。如果是大括号内为空,则简洁地写成{}即可,不需要换行;如果是非空代码块则:
1) 左大括号前不换行。
2) 左大括号后换行。
3) 右大括号前换行。
4) 右大括号后还有else等代码则不换行;表示终止右大括号后必须换行。
2. 【强制】 左括号和后一个字符之间不出现空格;同样,右括号和前一个字符之间也不出现空格。详见第5条下方正例提示。
3. 【强制】if/for/while/switch/do等保留字与左右括号之间都必须加空格。
4.【强制】任何运算符左右必须加一个空格。
说明:运算符包括赋值运算符=、逻辑运算符&&、加减乘除符号、三目运行符等。
5. 【强制】代码块缩进4个空格,如果使用tab缩进,请设置成1个tab为4个空格。
正例:(涉及1-5点)
public static void main(String args[]) {
// 缩进4个空格
String say = "hello";
//运算符的左右必须有一个空格
int flag = 0;
// 关键词if与括号之间必须有一个空格,括号内f与左括号,1与右括号不需要空格
if (flag == 0) {
System.out.println(say);
}
//左大括号前加空格且不换行;左大括号后换行
if (flag == 1) {
System.out.println("world");
// 右大括号前换行,右大括号后有else,不用换行
} else {
System.out.println("ok");
//右大括号做为结束,必须换行
【java开发规范(简洁版)】}
}
6. 【强制】单行字符数限制不超过120个,超出需要换行,换行时,遵循如下原则:
1) 换行时相对上一行缩进4个空格。
2) 运算符与下文一起换行。
3) 方法调用的点符号与下文一起换行。
4) 在多个参数超长,逗号后进行换行。
5) 在括号前不要换行,见反例。
正例:
StringBuffer sb = new StringBuffer();
//超过120个字符的情况下,换行缩进4个空格,并且方法前的点符号一起换行
sb.append("zi").append("xin")…
.append("huang");
反例:
StringBuffer sb = new StringBuffer();
//超过120个字符的情况下,不要在括号前换行
sb.append("zi").append("xin")…append
("huang");
//参数很多的方法调用也超过120个字符,逗号后才是换行处
method(args1, args2, args3, ...
, argsX);
7.【强制】方法参数在定义和传入时,多个参数逗号后边必须加空格。
正例:下例中实参的"a",后边必须要有一个空格。
method("a", "b", "c");
8.【推荐】没有必要增加若干空格来使某一行的字符与上一行的相应字符对齐。
正例:
int a = 3;
long b = 4L;
float c = 5F;
StringBuffer sb = new StringBuffer();
说明:增加sb这个变量,如果需要对齐,则给a、b、c都要增加几个空格,在变量比较多的情况下,是一种累赘的事情。
9. 【强制】IDE的textfile encoding设置为UTF-8; IDE中文件的换行符使用Unix格式,不要使用windows格式。
10.【推荐】方法体内的执行语句组、变量的定义语句组、不同的业务逻辑之间或者不同的语义之间插入一个空行。相同业务逻辑和语义之间不需要插入空行。
说明:没有必要插入多行空格进行隔开。
(四) OOP规约
1. 【强制】所有的覆写方法,必须加@Override注解。
反例:getObject()与get0bject()的问题。一个是字母的O,一个是数字的0,加@Override
可以准确判断是否覆盖成功。另外,如果在抽象类中对方法签名进行修改,其实现类会马上编
译报错。
2. 【强制】相同参数类型,相同业务含义,才可以使用Java的可变参数,避免使用Object。
说明:可变参数必须放置在参数列表的最后。(提倡同学们尽量不用可变参数编程)
正例:public User getUsers(String type, Integer... ids);
3.【强制】对外暴露的接口签名,原则上不允许修改方法签名,避免对接口调用方产生影响。接口过时必须加@Deprecated注解,并清晰地说明采用的新接口或者新服务是什么。
4.【强制】不能使用过时的类或方法。
5. 【强制】Object的equals方法容易抛空指针异常,应使用常量或确定有值的对象来调用equals。
正例:"test".equals(object);
反例:object.equals("test");
说明:推荐使用java.util.Objects#equals (JDK7引入的工具类)
6. 【强制】所有的相同类型的包装类对象之间值的比较,全部使用equals方法比较。
说明:对于Integervar=?在-128至127之间的赋值,Integer对象是在IntegerCache.cache产生,会复用已有对象,这个区间内的Integer值可以直接使用==进行判断,但是这个区间之外的所有数据,都会在堆上产生,并不会复用已有对象,这是一个大坑,推荐使用equals方法进行判断。
7.【强制】关于基本数据类型与包装数据类型的使用标准如下:
1) 所有的POJO类属性必须使用包装数据类型。
2) RPC方法的返回值和参数必须使用包装数据类型。
3) 所有的局部变量推荐使用基本数据类型。
说明:POJO类属性没有初值是提醒使用者在需要使用时,必须自己显式地进行赋值,任何NPE问题,或者入库检查,都由使用者来保证。
正例:数据库的查询结果可能是null,因为自动拆箱,用基本数据类型接收有NPE风险。
反例:某业务的交易报表上显示成交总额涨跌情况,即正负x%,x为基本数据类型,调用的RPC服务,调用不成功时,返回的是默认值,页面显示:0%,这是不合理的,应该显示成中划线-。所以包装数据类型的null值,能够表示额外的信息,如:远程调用失败,异常退出。
8. 【强制】定义DO/DTO/VO等POJO类时,不要设定任何属性默认值。
反例:某业务的DO的gmtCreate默认值为newDate(); 但是这个属性在数据提取时并没有置入具体值,在更新其它字段时又附带更新了此字段,导致创建时间被修改成当前时间。
9.【强制】序列化类新增属性时,请不要修改serialVersionUID字段,避免反序列失败;如果
完全不兼容升级,避免反序列化混乱,那么请修改serialVersionUID值。
说明:注意serialVersionUID不一致会抛出序列化运行时异常。
10.【强制】构造方法里面禁止加入任何业务逻辑,如果有初始化逻辑,请放在init方法中。
11.【强制】POJO类必须写toString方法。使用工具类source>generate toString时,如果继承了另一个POJO类,注意在前面加一下super.toString。
说明:在方法执行抛出异常时,可以直接调用POJO的toString()方法打印其属性值,便于排查问题。
12.【推荐】final可提高程序响应效率,声明成final的情况:
1) 不需要重新赋值的变量,包括类属性、局部变量。
2) 对象参数前加final,表示不允许修改引用的指向。
3) 类方法确定不允许被重写。
(五)注释规约
1. 【强制】类、类属性、类方法的注释必须使用javadoc规范,使用/**内容*/格式,不得使用//xxx方式。
说明:在IDE编辑窗口中,javadoc方式会提示相关注释,生成javadoc可以正确输出相应注释;在IDE中,工程调用方法时,不进入方法即可悬浮提示方法、参数、返回值的意义,提高阅读效率。
2. 【强制】所有的抽象方法(包括接口中的方法)必须要用javadoc 注释、除了返回值、参数、异常说明外,还必须指出该方法做什么事情,实现什么功能。
说明:如有实现和调用注意事项,请一并说明。
3.【强制】所有的类都必须添加创建者信息。
4. 【强制】方法内部单行注释,在被注释语句上方另起一行,使用//注释。方法内部多行注释使用/* */注释,注意与代码对齐。
5.【强制】所有的枚举类型字段必须要有注释,说明每个数据项的用途。
6.【推荐】与其“半吊子”英文来注释,不如用中文注释把问题说清楚。专有名词、关键字,保持英文原文即可。
反例:“TCP连接超时”解释成“传输控制协议连接超时”,理解反而费脑筋。
7.【推荐】代码修改的同时,注释也要进行相应的修改,尤其是参数、返回值、异常、核心逻辑等的修改。
说明:代码与注释更新不同步,就像路网与导航软件更新不同步一样,如果导航软件严重滞后,就失去了导航的意义。
8.【参考】注释掉的代码尽量要配合说明,而不是简单的注释掉。
说明:代码被注释掉有两种可能性:1)后续会恢复此段代码逻辑。2)永久不用。前者如果没有备注信息,难以知晓注释动机。后者建议直接删掉(代码仓库保存了历史代码)。
9.【参考】对于注释的要求:第一、能够准确反应设计思想和代码逻辑;第二、能够描述业务含义,使别的程序员能够迅速了解到代码背后的信息。完全没有注释的大段代码对于阅读者形同天书,注释是给自己看的,即使隔很长时间,也能清晰理解当时的思路;注释也是给继任者看的,使其能够快速接替自己的工作。
10.【参考】好的命名、代码结构是自解释的,注释力求精简准确、表达到位。避免出现注释的一个极端:过多过滥的注释,代码的逻辑一旦修改,修改注释是相当大的负担。
二、MySQL规约
(一)建表规约
1. 【强制】表达是与否概念的字段,必须使用is_xxx的方式命名,数据类型是unsignedtinyint( 1表示是,0表示否),此规则同样适用于odps建表。
说明:任何字段如果为非负数,必须是unsigned。
2.【强制】表名、字段名必须使用小写字母或数字;禁止出现数字开头,禁止两个下划线中间只出现数字。数据库字段名的修改代价很大,因为无法进行预发布,所以字段名称需要慎重考虑。
正例:getter_admin,task_config,level3_name
反例:GetterAdmin,taskConfig,level_3_name
3.【强制】表名不使用复数名词。
说明:表名应该仅仅表示表里面的实体内容,不应该表示实体数量,对应于DO类名也是单数形式,符合表达习惯。
4. 【强制】禁用保留字,如desc、range、match、delayed等,参考官方保留字。
5. 【强制】唯一索引名为uk_字段名;普通索引名则为idx_字段名。
说明:uk_ 即 unique key;idx_ 即index的简称。
6. 【强制】小数类型为decimal,禁止使用float和double。
说明:float和double在存储的时候,存在精度损失的问题,很可能在值的比较时,得到不正确的结果。如果存储的数据范围超过decimal的范围,建议将数据拆成整数和小数分开存储。
7. 【强制】如果存储的字符串长度几乎相等,使用CHAR定长字符串类型。
8. 【强制】varchar是可变长字符串,不预先分配存储空间,长度不要超过5000,如果存储长度大于此值,定义字段类型为TEXT,独立出来一张表,用主键来对应,避免影响其它字段索引效率。
9. 【强制】表必备三字段:id, gmt_create, gmt_modified。
说明:其中id必为主键,类型为unsignedbigint、单表时自增、步长为1;分表时改为从TDDL Sequence取值,确保分表之间的全局唯一。gmt_create, gmt_modified的类型均为date_time类型。
10.【推荐】表的命名最好是加上“业务名称_表的作用”,避免上云梯后,再与其它业务表关联时有混淆。
正例:tiger_task / tiger_reader / mpp_config
11.【推荐】库名与应用名称尽量一致。
12.【推荐】如果修改字段含义或对字段表示的状态追加时,需要及时更新字段注释。
13.【推荐】字段允许适当冗余,以提高性能,但是必须考虑数据同步的情况。冗余字段应遵循:
1)不是频繁修改的字段。
2)不是varchar超长字段,更不能是text字段。
正例:各业务线经常冗余存储商品名称,避免查询时需要调用IC服务获取。
14.【推荐】单表行数超过500万行或者单表容量超过2GB,才推荐进行分库分表。
说明:如果预计三年后的数据量根本达不到这个级别,请不要在创建表时就分库分表。
反例:某业务三年总数据量才2万行,却分成1024张表,问:你为什么这么设计?答:分1024张表,不是标配吗?
15.【参考】合适的字符存储长度,不但节约数据库表空间、节约索引存储,更重要的是提升检索速度。
正例:人的年龄用unsignedtinyint(表示范围0-255,人的寿命不会超过255岁);海龟就必须是smallint,但如果是太阳的年龄,就必须是int;如果是所有恒星的年龄都加起来,那么就必须使用bigint。
(二)索引规约
1.【强制】业务上具有唯一特性的字段,即使是组合字段,也必须建成唯一索引。
说明:不要以为唯一索引影响了insert速度,这个速度损耗可以忽略,但提高查找速度是明显的;另外,即使在应用层做了非常完善的校验和控制,只要没有唯一索引,根据墨菲定律,必然有脏数据产生。
2. 【强制】超过三个表禁止join。需要join的字段,数据类型保持绝对一致;多表关联查询时,保证被关联的字段需要有索引。
说明:即使双表join也要注意表索引、SQL性能。
3. 【强制】在varchar字段上建立索引时,必须指定索引长度,没必要对全字段建立索引,根据实际文本区分度决定索引长度。
说明:索引的长度与区分度是一对矛盾体,一般对字符串类型数据,长度为20的索引,区分度会高达90%以上,可以使用count(distinctleft(列名, 索引长度))/count(*)的区分度来确定。
4.【强制】页面搜索严禁左模糊或者全模糊,如果需要请走搜索引擎来解决。
说明:索引文件具有B-Tree的最左前缀匹配特性,如果左边的值未确定,那么无法使用此索引。
5. 【推荐】如果有order by的场景,请注意利用索引的有序性。order by最后的字段是组合索引的一部分,并且放在索引组合顺序的最后,避免出现file_sort的情况,影响查询性能。
正例:where a=? and b=? order by c; 索引:a_b_c
反例:索引中有范围查找,那么索引有序性无法利用,如:WHERE a>10 ORDER BY b; 索引a_b无法排序。
6.【推荐】利用覆盖索引来进行查询操作,来避免回表操作。
说明:如果一本书需要知道第11章是什么标题,会翻开第11章对应的那一页吗?目录浏览一下就好,这个目录就是起到覆盖索引的作用。
正例:IDB能够建立索引的种类:主键索引、唯一索引、普通索引,而覆盖索引是一种查询的一种效果,用explain的结果,extra列会出现:usingindex.
7.【推荐】利用延迟关联或者子查询优化超多分页场景。
说明:MySQL并不是跳过offset行,而是取offset+N行,然后返回放弃前offset行,返回N行,那当offset特别大的时候,效率就非常的低下,要么控制返回的总页数,要么对超过特定阈值的页数进行SQL改写。
正例:先快速定位需要获取的id段,然后再关联:
SELECT a.* FROM 表1 a, (select id from 表1where 条件 LIMIT 100000,20 ) b where a.id=b.id
8. 【推荐】SQL性能优化的目标:至少要达到range 级别,要求是ref级别,如果可以是consts最好。
说明:
1)consts单表中最多只有一个匹配行(主键或者唯一索引),在优化阶段即可读取到数据。
2)ref 指的是使用普通的索引。(normal index)
3)range对索引进范围检索。
反例:explain表的结果,type=index,索引物理文件全扫描,速度非常慢,这个index级别比较range还低,与全表扫描是小巫见大巫。
9.【推荐】建组合索引的时候,区分度最高的在最左边。
正例:如果wherea=?andb=?,a列的几乎接近于唯一值,那么只需要单建idx_a索引即可。
说明:存在非等号和等号混合判断条件时,在建索引时,请把等号条件的列前置。如:wherea>?
and b=? 那么即使a的区分度更高,也必须把b放在索引的最前列。
10.【参考】创建索引时避免有如下极端误解:
1)误认为一个查询就需要建一个索引。
2)误认为索引会消耗空间、严重拖慢更新和新增速度。
3)误认为唯一索引一律需要在应用层通过“先查后插”方式解决。
(三) SQL语句规约
1. 【强制】不要使用count(列名)或count(常量)来替代count(*),count(*)就是SQL92定义的标准统计行数的语法,跟数据库无关,跟NULL和非NULL无关。
说明:count(*)会统计值为NULL的行,而count(列名)不会统计此列为NULL值的行。
2. 【强制】count(distinct col) 计算该列除NULL之外的不重复数量。注意count(distinctcol1, col2) 如果其中一列全为NULL,那么即使另一列有不同的值,也返回为0。
3. 【强制】当某一列的值全是NULL时,count(col)的返回结果为0,但sum(col)的返回结果为NULL,因此使用sum()时需注意NPE问题。
正例:可以使用如下方式来避免sum的NPE问题:SELECTIF(ISNULL(SUM(g)),0,SUM(g))FROM table;
4. 【强制】使用ISNULL()来判断是否为NULL值。注意:NULL与任何值的直接比较都为NULL。
说明:
1)NULL<>NULL的返回结果是NULL,不是false。
2)NULL=NULL的返回结果是NULL,不是true。
3)NULL<>1的返回结果是NULL,而不是true。
5. 【强制】在代码中写分页查询逻辑时,若count为0应直接返回,避免执行后面的分页语句。
6.【强制】不得使用外键与级联,一切外键概念必须在应用层解决。
说明:(概念解释)学生表中的student_id是主键,那么成绩表中的student_id则为外键。
如果更新学生表中的student_id,同时触发成绩表中的student_id更新,则为级联更新。外
键与级联更新适用于单机低并发,不适合分布式、高并发集群;级联更新是强阻塞,存在数据
库更新风暴的风险;外键影响数据库的插入速度。
7.【强制】禁止使用存储过程,存储过程难以调试和扩展,更没有移植性。
8. 【强制】IDB数据订正时,删除和修改记录时,要先select,避免出现误删除,确认无误才能提交执行。
9. 【推荐】in操作能避免则避免,若实在避免不了,需要仔细评估in后边的集合元素数量,控制在1000个之内。
10.【参考】TRUNCATE TABLE 比 DELETE 速度快,且使用的系统和事务日志资源少,但TRUNCATE无事务且不触发trigger,有可能造成事故,故不建议在开发代码中使用此语句。
说明:TRUNCATE TABLE 在功能上与不带 WHERE 子句的 DELETE语句相同。
(四) ORM规约
1. 【强制】在表查询中,一律不要使用 *作为查询的字段列表,需要哪些字段必须明确写明。
说明:1)增加查询分析器解析成本。2)增减字段容易与resultMap配置不一致。
2. 【强制】POJO类的boolean属性不能加is,而数据库字段必须加is_,要求在resultMap中进行字段与属性之间的映射。
说明:参见定义POJO类以及数据库字段定义规定,在sql.xml增加映射,是必须的。
3. 【强制】不要用resultClass当返回参数,即使所有类属性名与数据库字段一一对应,也需要定义;反过来,每一个表也必然有一个与之对应。
说明:配置映射关系,使字段与DO类解耦,方便维护。
4. 【强制】xml配置中参数注意使用:#{},#param# 不要使用${} 此种方式容易出现SQL注入。
5. 【强制】iBATIS自带的queryForList(StringstatementName,int start,int size)不推荐使用。
说明:其实现方式是在数据库取到statementName对应的SQL语句的所有记录,再通过subList取start,size的子集合,线上因为这个原因曾经出现过OOM。
正例:在sqlmap.xml中引入#start#, #size#
Map map = new HashMap();
map.put("start", start);
map.put("size", size);
6. 【强制】不允许直接拿HashMap与HashTable作为查询结果集的输出。
反例:某同学为避免写一个,直接使用HashTable来接收数据库返回结果,结果出现日常是把bigint转成Long值,而线上由于数据库版本不一样,解析成BigInteger,导致线上问题。
7. 【强制】更新数据表记录时,必须同时更新记录对应的gmt_modified字段值为当前时间。
8. 【推荐】不要写一个大而全的数据更新接口,传入为POJO类,不管是不是自己的目标更新字段,都进行update table set c1=value1,c2=value2,c3=value3; 这是不对的。执行SQL时,尽量不要更新无改动的字段,一是易出错;二是效率低;三是binlog增加存储。
9. 【参考】@Transactional事务不要滥用。事务会影响数据库的QPS,另外使用事务的地方需要考虑各方面的回滚方案,包括缓存回滚、搜索引擎回滚、消息补偿、统计修正等。
五、安全规约
1.【强制】可被用户直接访问的功能必须进行权限控制校验。
说明:防止没有做权限控制就可随意访问、操作别人的数据,比如查看、修改别人的订单。
2.【强制】用户敏感数据禁止直接展示,必须对展示数据脱敏。
说明:支付宝中查看个人手机号码会显示成:158****9119,隐藏中间4位,防止隐私泄露。
3. 【强制】用户输入的SQL参数严格使用参数绑定或者METADATA字段值限定,防止SQL注入,禁止字符串拼接SQL访问数据库。
4.【强制】用户请求传入的任何参数必须做有效性验证。
说明:忽略参数校验可能导致:
lpage size过大导致内存溢出
l恶意order by导致数据库慢查询
l正则输入源串拒绝服务ReDOS
l任意重定向
lSQL注入
lShell注入
l反序列化注入
5. 【强制】禁止向HTML页面输出未经安全过滤或未正确转义的用户数据。
6. 【强制】表单、AJAX提交必须执行CSRF安全过滤。
说明:CSRF(Cross-siterequestforgery)跨站请求伪造是一类常见编程漏洞。对于存在CSRF漏洞的应用/网站,攻击者可以事先构造好URL,只要受害者用户一访问,后台便在用户不知情情况下对数据库中用户参数进行相应修改。
7. 【强制】URL外部重定向传入的目标地址必须执行白名单过滤。
正例:
try {
if (com.alibaba.fasttext.sec.url.CheckSafeUrl
.getDefaultInstance().inWhiteList(targetUrl)){
response.sendRedirect(targetUrl);
}
} catch (IOException e) {
logger.error("Check returnURL error! targetURL=" + targetURL, e);
throw e;
8. 【强制】Web应用必须正确配置Robots文件,非SEOURL必须配置为禁止爬虫访问。
User-agent: * Disallow: /
9.【强制】在使用平台资源,譬如短信、邮件、电话、下单、支付,必须实现正确的防重放限制,如数量限制、疲劳度控制、验证码校验,避免被滥刷、资损。
说明:如注册时发送验证码到手机,如果没有限制次数和频率,那么可以利用此功能骚扰到其它用户,并造成短信平台资源浪费。

    推荐阅读