mongodb角色无法限制$near或$geowithin，因其所有地理空间查询均归类为find行为；只要用户具备read权限且集合建有2dsphere索引，即可执行任意空间查询，官方未提供georead等专用角色。
为什么不能靠MongoDB角色限制$near或$geoWithin
MongoDB的权限系统根本不识别地理空间操作——$near、$geoWithin、$geoIntersects 全部被归类为 find 行为。只要用户对集合有 read 角色（或显式 find 权限），且该集合存在 2dsphere 索引，就能直接执行任意空间查询。官方从未提供 geoRead 或类似内置角色，rolesInfo 命令里也查不到任何 geo 相关 privilege。
真正有效的三层拦截点
想控制谁能看到/查哪些地理位置数据，必须在三个层面协同设防：
-
网络层：用
mongod.conf中的net.bindIp严格限定可连接 IP 段，例如只放行内网服务网段（10.0.0.0/8），禁止公网直连； -
认证层：启用
security.authorization: enabled，为不同应用创建最小权限用户——比如给地图前端服务只授予read角色到places库的poi集合，绝不给admin或readWriteAnyDatabase； -
应用层：这是最灵活也最关键的环节，必须在业务代码中校验查询意图——例如拒绝
coordinates字段出现在$where、聚合管道的$expr或未授权字段投影中。
GeoJSON 明文泄露比空间查询更危险
很多人以为只要拦住 $near 就安全了，但实际风险常来自普通 find：
- 一个有
read权限的用户执行db.places.find({name: "Beijing Tower"}, {location: 1})，结果里location.coordinates就是明文[116.4, 39.9]； - 敏感位置（如用户实时定位、配送员轨迹）绝不能依赖权限隐藏，必须加密存储（如用 AES 加密
coordinates字段）； - 前端 SDK 或第三方集成不应直接连 MongoDB，必须走后端 API，且 API 要做字段裁剪（不返回
coordinates）、范围过滤（如仅允许查city == "Shanghai"的 POI）； - 审计日志需监控高频空条件
find({})或大范围投影（如{location: 1}），这类请求往往预示数据爬取行为。
网关层过滤的关键实现点
在 API 网关（如 Kong、Nginx + Lua、Spring Cloud Gateway）中拦截地理查询，重点不是解析 BSON，而是识别高危模式：
- 拦截包含
$near、$geoNear、$geoWithin的请求体（注意大小写和嵌套层级）； - 检查 URL 参数或 JSON body 中是否含
coordinates、geometry、center等关键词，结合白名单路径（如只允许/api/v1/nearby）放行； - 对非白名单客户端（如来源 IP 不在
trusted_clients列表），强制重写查询：把coordinates替换为固定值（如[0, 0]）或直接返回 403； - 避免在网关做复杂 GeoJSON 解析——性能差且易绕过，真正校验应下沉到业务服务层，网关只做快速模式匹配和黑白名单决策。
