l 反序列化注入
l 正则输入源串拒绝服务 ReDoS
说明：Java 代码用正则来验证客户端的输入，有些正则写法验证普通用户输入没有问题， 但是如果攻击人员使用的是特殊构造的字符串来验证，有可能导致死循环的结果。
2. 【强制】禁止向 HTML 页面输出未经安全过滤或未正确转义的用户数据。
3. 【强制】表单、AJAX 提交必须执行 CSRF 安全验证。
说明：CSRF(Cross-site request forgery)跨站请求伪造是一类常见编程漏洞。对于存在
CSRF 漏洞的应用/网站，攻击者可以事先构造好 URL，只要受害者用户一访问，后台便在用户不知情的情况下对数据库中用户参数进行相应修改。
4. 【推荐】为包含敏感信息或功能、且连接到外部系统的连接使用 TLS。
5. 【强制】不要在 HTTP GET请求参数中包含敏感信息。
6. 【强制】禁止表单中的自动填充功能，因为表单中可能包含敏感信息，包括身份验证信息。
7. 【强制】禁止客户端缓存网页，因为可能包含敏感信息。“Cache-Control: no-store”，可以和 HTTP报头控制“Pragma: no-cache”一起使用，该控制不是非常有效，但是与 HTTP/1.0向后兼容。
8. 【推荐】为防范对随机数据的猜测攻击，应当使用加密模块中已验证的随机数生成器生成所有的随机数、随机文件名、随机 GUID和随机字符串。
9. 【强制】不要在错误响应中泄露敏感信息，包括：系统的详细信息、会话标识符或者帐号信息。
10. 【推荐】不要在日志中保存敏感信息，包括：不必要的系统详细信息、会话标识符或密码。
11. 【强制】限制只有授权的用户才能访问受保护的 URL。
12. 【强制】不要在 URL、错误信息或日志中暴露会话标识符。会话标识符应当只出现在 HTTP cookie头信息中。比如，不要将会话标识符以 GET 参数进行传递。
13. 【推荐】如果任何潜在的 危险字符 必须被作为输入，请确保您执行了额外的控制，比如：输出编码、特定的安全 API、以及在应用程序中使用的原因。部分常见的危险字符包括：< > ” ‘ % ( ) & + ’ ” 。
(四)身份认证
1. 【推荐】为所有要求身份验证的访问内容和所有其他的敏感信息提供 TLS连接
2. 【强制】在身份验证的时候，如果连接从 HTTP变为 HTTPS，则生成一个新的会话标识符。在应用程序中，推荐持续使用 HTTPS，而非在 HTTP和 HTTPS之间转换。
3. 【强制】所有的身份验证过程必须在可信系统(比如：服务器)上执行，身份验证的失败提示信息应当避免过于明确。比如：可以使用“用户名和/或密码错误”，而不要使用“用户名错误”或者“密码错误”。错误提示信息在显示和源代码中应保持一致。
三、MySQL 数据库
(一) 建表规约
1. 【强制】表名必须以t_开头，如：t_user，函数以f_开头，存储过程已p_开头，视图以v_开头。
2. 【强制】字段名按照不同的数据类型进行命名，字符、文本类型以c_开头，如：c_user_name,整型(包含int,tinyint,bigint)、数字类型都统一以n_开头、时间类型用长时间格式进行存储，也以n_开头，double数据类型以d_开头，float数据类型以f_开头。
3. 【强制】表名、字段名必须使用小写字母或数字，禁止出现数字开头，禁止两个下划线中间只出现数字。数据库字段名的修改代价很大，因为无法进行预发布，所以字段名称需要慎重考虑。说明：MySQL 在 Windows 下不区分大小写，但在 Linux 下默认是区分大小写。因此，数据库名、表名、字段名，都不允许出现任何大写字母，避免节外生枝。
正例：super_admin，rpc_config，level3_name 反例：superAdmin，rpcConfig，level_3_name
4. 【强制】表名不使用复数名词。
说明：表名应该仅仅表示表里面的实体内容，不应该表示实体数量，对应于 DO 类名也是单数形式，符合表达习惯。
5. 【强制】禁用保留字，如 desc、range、match、delayed 等，请参考 MySQL 官方保留字。
6. 【强制】主键索引名为 pk_字段名;唯一索引名为 uk_字段名;普通索引名则为 idx_字段名。说明：pk_ 即 primary key;uk_ 即 unique key;idx_ 即 index 的简称。
7. 【强制】varchar 是可变长字符串，不预先分配存储空间，长度不要超过 5000，如果存储长度大于此值，定义字段类型为 text，独立出来一张表，用主键来对应，避免影响其它字段索引效率。
8. 【推荐】库名与应用名称尽量一致。
9. 【推荐】如果修改字段含义或对字段表示的状态追加时，需要及时更新字段注释。