1.概述

目前删除数据，编辑数据，查看数据 我们是通过ID进行处理的。
这些ID都是趋势递增的ID，这种情况下，如果我们没有对数据进行逐条权限验证的情况下，攻击者很容易根据ID猜出其他的ID。
比如攻击者可以使用一个循环调用接口删除数据。这种危险性很大。

解决办法：
我们的数据都是增查改删的情况，这些是通用的，因此，我们希望通过统一的方式进行处理。
ID在数据库库存储时，还是使用原来的方式。在列表的时候，返回的主键为加密的ID。
当传入加密的ID到控制器的时候，我们需要将这些ID解密后，再进行实际的操作。
这样攻击者就没有办法猜测加密的ID，从而防止攻击。
比如删除数据：
我们应该是传入加密后的ID数据，后端解密这个数据再做删除处理。

2.nacos配置

在nacos-config.properties 配置是否对列表数据的主键进行加密：

props.isEncryptId=true

备注：true是，false否

3.操作

3.1. BaseController的封装

平台已经对BaseController这个基础类进行了相关的封装。最佳实践，我们在开发的过程中，相关的控制器只要继承这个父类，直接使用其相关的方法，就自动拥有对ID加密、解密的能力。
BaseController中，列表查询【query】、列表查询(不分页)【queryList】、查询当前业务表的所有数据【getAll】等3个方法对ID进行了加密操作；根据ID查询明细【get】、根据主键IDS查询业务数据详细信息【getByIds】、保存业务数据记录【save】、删除业务行数据【del】等4个方法对ID进行了解密操作。

3.2. 重写或者新建其它的方法

在控制器类中，如果对上面提到的7个方法进行重写，或者新建其它方法，则需要手动对ID进行加密、解密。BaseController提供了一个对ID加密方法【encryptList】，两个对ID解密的方法【decryptId、decryptIdList】，可以直接调用。

3.3. BaseService的封装

BaseService基础类的get方法已经对ID进行解密，在调用该方法时，无需对ID进行额外的解密处理。

3.4. 底层加解密的EncryptUtil类调用

此外，如果上面提到的几个操作方式，都无法满足实际需求，则可以直接调用底层的EncryptUtil类，对ID进行加解密。其中，encryptId是加密方法，decryptId是解密方法。