小程序云数据库安全与权限实战：规则与敏感字段

云数据库为什么要做权限

用云开发的时候，前端可以直接连云数据库读写数据。方便是方便，但如果权限没设好，任何用户都能把整表数据读走、甚至改掉别人的记录。数据安全就出大问题了。

云数据库提供权限规则，让你精确控制「谁能读、谁能写、读到哪一步」。这层规则是前端直连数据库时的第一道也是最关键的一道防线。

很多新手图方便，建集合的时候直接默认「所有用户可读写」，觉得自己前端没写敏感操作就没事。但只要有人在前端控制台里直接发查询，整表数据就可能被拉走。权限这件事，必须在建库的时候就按最小权限配好，不能等出事再补。

本文核心知识点

每个集合都能设权限。常见的几种：所有用户可读仅创建者可写、仅创建者可读写、仅管理端可读写。按集合的用途选，别图省事全选「所有用户可读写」。

拿不准选哪个的时候，往严了选。权限配严了大不了走云函数绕一下，配松了就是把数据大门敞开。等用户量上来、数据变敏感，再想收紧就被动了。

用户的订单、收藏、个人信息，必须按用户本人隔离。每条记录存上 openid，查询和写入都带「只能是我自己的 openid」这个条件。这样 A 用户读不到 B 用户的数据。

db.collection("orders")
  .where({ _openid: "{openid}" })
  .get();

权限规则里把这个隔离写成规则，比每条查询手动加条件更稳妥，也防止前端漏写。

这里有个常见的偷懒做法：前端查询时不带 openid，而是在后端接口里再判断。但既然用了云数据库直连，就该把隔离写进规则，别把判断完全押在前端代码上。规则写好之后，哪怕前端代码被人绕过，数据库本身也会拒绝不该有的访问。

有些字段不该让前端拿到，比如用户的手机号中间位、内部的金额成本、其他用户的标识。查询时用 field 指定只取需要的字段，别把整条记录拉回来。

拿不准某个字段能不能下发，就先不下发，等真的需要了再放开。前端多查一个字段看起来省事，但那个字段一旦被滥用或者泄露，收回来就难了。

权限规则是第一道，但涉及钱、涉及敏感写入的操作，还要在云函数里再校验一次。不能只靠规则就放心，万一规则配错，云函数这层还能兜住。

权限规则管大门，云函数管里屋，两层都要有。

具体说，凡是涉及改钱、改库存、删数据的操作，都不该让前端直接写库，而要走云函数。云函数里用管理员权限操作数据库，同时在函数内部再校验一遍这个用户有没有资格做这件事。这样哪怕规则配宽了，云函数也能稳稳挡住越权的危险操作。

两层防线加起来，数据就稳了：规则挡住大部分误操作，云函数兜住越权的关键写入。

数据安全不是配一次就完事，要一直盯着。