【架构】API接口安全防护救命的11招

前言

如何保证接口的安全性？

根据多年的工作经验，给大家介绍一下保证接口安全的一些小技巧，希望对你会有所帮助。

1 参数校验

保证接口安全的第一步，也是最重要的一步，需要对接口的请求参数做校验。

如果我们把接口请求参数的校验做好了，真的可以拦截大部分的无效请求。

我们可以按如下步骤做校验：

1. 校验参数是否为空，有些接口中可能会包含多个参数，有些参数允许为空，有些参数不允许为空，我们需要对这些参数做校验，防止接口底层出现异常。

2. 校验参数类型，比如：age是int类型的，用户传入了一个字符串："123abc"，这种情况参数不合法，需要被拦截。

3. 校验参数的长度，特别是对于新增或者修改数据接口，必须要做参数长度的校验，否则超长了数据库会报异常。比如：数据库username字段长度是30，新用户注册时，输入了超过30个字符的名称，需要提示用户名称超长了。虽说前端会校验字段长度，但接口对参数长度的校验也必不可少。

4. 校验枚举值，有些接口参数是枚举，比如：status，数据库中设计的该字段只有1、2、3三个值。如果用户传入了4，则需要提示用户参数错误。

5. 校验数据范围，对于有些金额参数，需要校验数据范围，比如：单笔交易的money必须大于0，小于10000。

我们可以自己写代码，对每个接口的请求参数一一做校验。

也可以使用一些第三方的校验框架。

比如：hiberate的Validator框架，它里面包含了@Null、@NotEmpty、@Size、@Max、@Min等注解。

用它们校验数据非常方便。

当然有些日期字段和枚举字段，可能需要通过自定义注解的方式实现参数校验。

2 统一封装返回值

可能有些小伙伴认为，对接口返回值统一封装是为了让代码更规范。

其实也是处于安全方面的考虑。

假如有这样一种场景：你写的某个接口底层的sql，在某种条件下有语法问题。某个用户请求接口之后，在访问数据库时，直接报了sql语法错误，将数据库名、表名、字段名、相关sql语句都打印出来了。

此时，如果你的接口将这些异常信息直接返回给外网的用户，有些黑客拿着这些信息，将参数做一些调整，拼接一些注入sql，可以对你的数据库发起攻击。

因此，非常有必要对接口的返回值做统一的封装。

例如下面这样：

复制{ "code":0, "message":null, "data":[{"id":123,"name":"abc"}] }

该json返回值中定义了三个字段：

• code：表示响应码，0-成功，1-参数为空，2-参数错误，3-签名错误 4-请求超时 5-服务器内部错误等。

• message：表示提示信息，如果请求成功，则返回空。如果请求失败，则返回我们专门在代码中处理过࿰