数据安全：后端接口中少量看似多余的参数

【IT老五】数据安全：后端接口中少量看似多余的参数

后端接口开发与前台开发有不少不同，在并发、性能、容错、安全等方面都需要有肯定的考虑……而且因为后端接口往往是直接或者者间接的对数据库进行操作，所以在提供一个接口时，往往要考虑数据库数据能否有可能被人通过该接口恶意拷贝、修改甚至删除……

接口

我这里就最近碰到的一种现象来吐槽下：GetReportById(int reportId)；看上去，这个接口很简单，功能也很明确，通过报告id查找报告，貌似没什么问题…

问题

但是，假如为该接口加上少量前提呢？首先该报告是与客户绑定的，其次该报告查看功能是不需登录的……此时，再来看看该接口：仅需一个报告id就可以获取到报告内容，一般情况下，这个报告id是主键，而且是自增的，那么，我导出数据库所有的报告只要要从1开始不断地改变入参reportId就可，显然，这是非常不安全的…（当然，可能有人觉得可以依托于其余方式来防止该问题，如IP调用限制、数据加密、入参id加密等）

【IT老五】数据安全：后端接口中少量看似多余的参数

处理

先来说说当我们没有使用数据加密时，有什么办法来防止数据通过接口循环导出？

1. 数据校验

想想，我们上面说的前提，报告是属于客户的，那么我们简单的修改下接口，改成GetReportById(int reportId, it userId)，在通过报告id获取报告时校验下能否属于该客户，则可以防止数据被简单的循环导出了。

2. 入参与密

另外，更深一个层次，我们队入参id进行加密，使入参不再单纯的是自增id，而是一种无规律的字符串，那么，就对数据的保护是不是就更强了？

比方我们定一个id的加密方法（这里只是一个简单的示例）：

原id为： reportId = 1；定义一个随机值： code = new Random().nextInt(100);加密后的id为： encryptId = (reportId + code) * 5;解密获取原id： reportId = encryptId / 5 - code;

此时，我们的接口应该是GetReportById(encryptId, int code, it userId)，当然，userId也可以进行加密，这里只是作为示例就不考虑这么多了…

3. 出参与密

即对数据出参进行加密，此时一般都会用到时间戳之类的作为加解密因子，所以接口可能会变为GetReportById(int encryptId, int code, long timestamp, it userId)

【IT老五】数据安全：后端接口中少量看似多余的参数

总结

相对于最初的GetReportById(int reportId)而言，后面的三个操作都带入了基础业务上不需要的参数，这些参数看上去的确是多余的。

由于我只要要报告，通过id查找报告，很简单的一个实现，而最后却加了一堆不解释看不懂的参数，可能会让人感觉莫名其妙。然而，这些参数却能处理数据安全问题，可谓“冗余并不肯定是坏的”。

简书：ThinkinLiu 博客: IT老五

ps: 最近这段时间该webapi经常看到少量GetReportById(int reportId)类型的接口，所以就写了这篇文章，谈谈自己的看法，解除后端开发不久，如写得有问题，或者者因为我知识面浅薄，有其余方式或者在其余层面已经处理了该问题（不再需要考虑这种安全性问题），欢迎指教…

IT老五（it-lao5）：关注公众号，一起源创，一起学习！