开发者提供的信息检索接口使用数字自增 ID（或有特定规律）作为查询参数，且接口不做人机和登录鉴权校验，很容易造成数据信息被拖库。
比如：A 小程序有会员服务，会员 ID 是自增的，恶意用户 1 按照会员 ID 规律伪造请求，使用原本用于会员报名的接口，获取了 A 小程序的全部会员信息；且接口返回的信息未做任何隐私保护，恶意用户 1 掌握了所有会员的手机号、姓名、地址等隐私信息，属于重大隐私泄露案例。
很多开发者都习惯使用自增 ID 作为订单号、任务 ID 等关键的索引，但如果接口未做鉴权和隐私信息保护，很有可能被恶意分子利用，偷取大量关键信息，对自身业务造成损失。
处理建议
ID 信息不应该使用简单的递增，如必须递增则后缀应添加随机码，后端在查询时，应拆出随机码进行校验。随机码相当于为每个 ID 加了密码，恶意分子很难批量伪造。
如保证更安全，可叠加使用对称加密方式将 ID 做对称加密处理，服务端只接收加密处理的 ID 查询请求。减少恶意分子的规律发现，从而放弃。
不要在业务中以用户列表的形式展示所有用户，只在业务必要时提供。
eg：比如社区应用，只在帖子和评论里包含用户信息，或通过链接直接访问用户信息，不要在一个页面板块中展示所有用户，这相当于为恶意分子主动送信息，省去了其规律拼凑 ID 的步骤。
