> 说明：本文所有实测均在**自己的应用**上进行，探测行为只写入/删除自己插入的测试行，不涉及任何他人数据。

---

## 一、背景：这类应用的架构

现在很多轻量应用是这个形态：

- 前端是纯静态页面，托管在公网
- 数据存在云数据库里，通过 PostgREST 风格的 REST 接口读写
- 前端 `js` 里**明文**放着一个 `publishableKey`（公开 key），用来发起请求

**公开 key 明文放在前端是正常设计**——它的定位就是"只能干公开能干的事"，真正的权限边界应该由**服务端的行级安全策略（RLS）**来划。所以安全与否，取决于后端的策略写得对不对。

## 二、起因：顺手查了一下权限

原本在做的是"数据量涨上来会不会卡"的容量体检，看到数据库就顺手查了一下角色授权：

```sql
SELECT grantee, privilege_type
FROM information_schema.role_table_grants
WHERE table_schema = 'public' AND table_name = 'merchants'
ORDER BY grantee, privilege_type;
```

结果看到 `anon` 角色（未登录访客）**同时持有 `INSERT`、`UPDATE`、`DELETE`**。

## 三、我犯的错：用 DELETE 的返回值判断权限

**第一版结论（错的）**：我发了一个删除请求，服务端返回 `204`，我据此判断"能删"。

这个判断是**错的**，而且错得很有代表性：

> **`DELETE` 不匹配任何行时，同样返回 `204`。**

也就是说，`204` 只能说明"请求被处理了"，**完全无法区分**下面两种情况：

- 权限放行，但没匹配到行 → 删了 0 行 → `204`
- 权限被拒 → 也是 `204`（或 `200`）

**光看 DELETE 的返回码，永远分不清"删了 0 行"和"没权限"。** 我进一步验证了这一点：用公开 key 去改一条真实记录，改完再读回来——**内容一字未变**。说明 `UPDATE` 实际上是被拦住的。

所以第一版结论里"能改能删"这半句，是误判。

## 四、关键事实校正：RLS 其实是开着的

我又查了一遍策略，发现事实和我以为的不一样：

```sql
SELECT c.relname, c.relrowsecurity AS rls_on,
       (SELECT count(*) FROM pg_policies p
        WHERE p.schemaname = 'public' AND p.tablename = c.relname) AS policies
FROM pg_class c
JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE n.nspname = 'public' AND c.relkind = 'r';
```

**结果是：RLS（行级安全）已经启用**，而且策略写得挺规范：

| 策略 | 命令 | 条件 |
|---|---|---|
| `merchants_read_all` | SELECT | `true`（所有人可读） |
| `merchants_insert_own` | INSERT | `owner_id = auth.uid()` |
| `merchants_update_own` | UPDATE | `owner_id = auth.uid()` |
| `merchants_delete_own` | DELETE | `owner_id = auth.uid()` |

看到这里，我上一轮说"门禁没打开"也是错的——**门禁开着，规则也在**。

那问题出在哪？

## 五、正确的判定方法：用 INSERT 区分

因为 RLS 开着，`SELECT/UPDATE/DELETE` 都受策略约束，返回码无法区分"拒绝"和"匹配 0 行"。**唯一能明确区分的是 INSERT**：

- 权限被拒 → `401` / `403` / `42501`（违反安全策略）
- 权限放行 → `201`，或者数据校验错误（如非空约束）——**总之不是权限错误**

实测请求（只测返回码，故意让数据不合格，避免写入真实数据）：

```bash
curl -s -o /dev/null -w "%{http_code}\n" \
  -X POST "$ENDPOINT/database/rest/merchants" \
  -H "x-wb-webapp-access-key: $PUBLISHABLE_KEY" \
  -H "Content-Type: application/json" \
  -H "Prefer: return=minimal" \
  -d '{"name":"__probe__"}'
```

**结果：`201`。**

为了定性，我做了一次完整写入测试（插入一行明显是测试用途的数据，随后立即删除），然后查库：

```
id | name            | owner_id
55 | __权限体检_请忽略__ | anon
```

**`owner_id` 被自动填成了字符串 `'anon'`。** 漏洞确认。

## 六、根因：一个会"自我满足"的条件

问题出在策略条件本身：

```sql
-- 原策略（有问题）
CREATE POLICY merchants_insert_own ON merchants
  FOR INSERT WITH CHECK (owner_id = auth.uid());
```

看起来是"只能插入属于我自己的数据"，很合理。但看两个细节：

**细节一**：`owner_id` 字段的默认值是 `auth.uid()`。

```sql
owner_id text DEFAULT auth.uid()
```

**细节二**：`auth.uid()` 在**未登录**时，平台会兜底返回**角色名 `'anon'`**，而不是 `NULL`。

于是未登录用户插入数据时：

```
WITH CHECK (owner_id = auth.uid())
         →  ('anon'  =  'anon')
         →  TRUE   ✅ 通过
```

**`owner_id` 由默认值自动填成 `'anon'`，判定条件也读出 `'anon'`——自己跟自己比，当然成立。**

这就是这个写法最隐蔽的地方：它不是"策略写错了"，而是**策略在匿名场景下会自我满足**。规则本身没毛病，但它假设了"未登录时 `auth.uid()` 会是 NULL"——而这个前提不成立。

## 七、危害：能贴广告，还撕不下来

漏洞确凿之后，实际影响是：

1. **任何人**只要从网页源码里复制那个公开 key，就能往表里插数据——广告、假信息、垃圾内容
2. **而管理员在后台删不掉它**：后台的删除逻辑是"只能删自己录入的"（按 `owner_id` 过滤），插入行的 `owner_id` 是 `'anon'`，后台会提示"这不是你录入的"
3. 等于**别人能往你家墙上贴广告，你还撕不下来**

**好消息是**：原有的 14 条数据 `owner_id` 都是管理员本人的账号 ID，**没有被污染，也改不掉删不掉**（这部分策略是对的）。

## 八、修法：把"数据所有权"换成"管理员白名单"

原策略的问题是"用数据自身的属性做写入门禁"。正确的思路是：

> **写操作不判断"数据是谁的"，只判断"你是不是管理员本人"。**

```sql
DO $$
BEGIN
  DROP POLICY IF EXISTS merchants_insert_own ON public.merchants;
  DROP POLICY IF EXISTS merchants_update_own ON public.merchants;
  DROP POLICY IF EXISTS merchants_delete_own ON public.merchants;
  DROP POLICY IF EXISTS merchants_read_all     ON public.merchants;

  -- 读：保持公开
  CREATE POLICY merchants_read_public ON public.merchants
    FOR SELECT USING (true);

  -- 写：只有这一个账号（已登录）
  CREATE POLICY merchants_insert_admin ON public.merchants
    FOR INSERT WITH CHECK (auth.uid() = '<你的管理员UID>');

  CREATE POLICY merchants_update_admin ON public.merchants
    FOR UPDATE USING (auth.uid() = '<你的管理员UID>')
    WITH CHECK (auth.uid() = '<你的管理员UID>');

  CREATE POLICY merchants_delete_admin ON public.merchants
    FOR DELETE USING (auth.uid() = '<你的管理员UID>');
END
$$;
```

核心变化：**`auth.uid()` 不再和"数据里的字段"比，而是和"写死的管理员 ID"比。** 匿名用户（`auth.uid()` = `'anon'`）永远不满足条件。

## 九、三重验证：门关上了，门里的人还能进

改完不能只看策略列表。必须证明**三件事**：

**① 策略确实替换到位**

```sql
SELECT policyname, cmd, qual, with_check
FROM pg_policies
WHERE schemaname='public' AND tablename='merchants';
```

四条新策略（1 读 3 写）都在，`with_check` 里是管理员 ID 而不是 `owner_id`。

**② 模拟"登录状态"的令牌，确认 `auth.uid()` 返回值正确**

```sql
WITH s AS (
  SELECT set_config('request.jwt.claims',
    '{"sub":"<你的管理员UID>","role":"authenticated"}', true) AS x
)
SELECT (SELECT x FROM s) IS NOT NULL AS claims_set,
       auth.uid() AS uid_when_logged_in;
```

返回的 `uid_when_logged_in` **正是你自己的管理员 UID** ——说明登录后能通过新策略，**管理员的录入不受影响**。这一步是整个验证里最关键的一环：光堵住匿名还不够，堵错了会把管理员一起堵死。

**③ 真实攻击测试（同一把公开 key）**

| 用公开 key 试 | 修复前 | 修复后 |
|---|---|---|
| INSERT 一条数据 | **201 成功写入** | **401 拒绝**（违反安全策略） |
| UPDATE 已有数据 | 无效（原内容未变） | 无效 |
| DELETE 已有数据 | 无效 | 无效 |
| 读名录 | 正常 | 正常 |
| 数据条数 | 14 | 14 |

## 十、副作用排查（这一步最容易漏）

改权限最大的风险是**误伤自己**。所以我把所有写操作都过了一遍：

**① 有一个匿名写操作：浏览量 +1**

前端打开详情页时会调用一个 `bump_views` 函数给浏览量加一。查它的定义后确认：

```sql
prosecdef = true   -- SECURITY DEFINER
```

**`SECURITY DEFINER`** 意味着这个函数**以定义者权限运行**，不受调用者的 RLS 限制。所以**访客的浏览量统计照常工作**，没有被误伤。

**② 后台录入页需要登录**

录入、批量导入、地图标点这几个页面本身都要求登录后才可用，管理员账号在新白名单里 → 不受影响。

**③ 全库扫一遍有没有别的可滥用函数**

```sql
SELECT p.proname, pg_get_function_arguments(p.oid) AS args,
       p.prosecdef AS security_definer,
       left(pg_get_functiondef(p.oid), 220) AS def_head
FROM pg_proc p
JOIN pg_namespace n ON n.oid = p.pronamespace
WHERE n.nspname = 'public';
```

全库只有 `bump_views` 一个函数，且只能"加一"，无法被滥用。**无其他后门。**

## 十一、三条可以带走的经验

**一、别只看 GRANT，要看策略。** `role_table_grants` 显示 `anon` 有 `INSERT/UPDATE/DELETE`，很容易被理解成"开放了写权限"；但如果 RLS 开着且有策略，实际权限完全由策略决定。**授权（GRANT）和策略（RLS）是两层，别把第一层当成结论。**

**二、别用 `DELETE` 的返回码判断权限。** 不匹配行也是 `204`，"删了 0 行"和"没权限"在 HTTP 层长得一模一样。**要判断写权限，用 `INSERT`**（`201` vs `401/42501`）。同理，也**别用"更新后内容没变"来判断**——那可能只是你更新的是同一个值。

**三、写入门禁不要用"数据自身的属性"做条件。** `owner_id = auth.uid()` 看起来天经地义，但在匿名场景下会自我满足。**写操作的判定条件里，应该出现一个"攻击者无法影响"的常量**（比如写死的管理员 ID），而不是数据里可以被自动填充的字段。

---

## 附：这类检查的通用清单

如果你也做"静态页 + 云数据库"的应用，建议按这个顺序自查：

1. 表是否启用了 RLS？（`pg_class.relrowsecurity`）
2. 每张表有几条策略？覆盖了 `SELECT / INSERT / UPDATE / DELETE` 吗？（`pg_policies`）
3. 写策略的条件里，有没有"可以被自动填充的字段"？（重点怀疑 `DEFAULT auth.uid()` 这类）
4. 用 `INSERT` 做一次真实探测（在**自己的库**上，测试行随后删掉），看返回 `201` 还是 `401`
5. 数据里有没有"匿名归属"的行？（`SELECT owner_id, count(*) FROM t GROUP BY owner_id`）
6. 库里有没有 `SECURITY DEFINER` 的函数？它们绕过了 RLS，逐个看过

---

*本文的排查与验证由 WorkBuddy 辅助完成：数据库策略查询、函数定义比对、HTTP 返回码探测、以及改动前后的对照验证，均通过脚本实测。整个过程对原有数据零改动。如果你在自己的应用上发现类似问题，欢迎在评论区交流。*

说明：本文所有实测均在自己的应用上进行，探测行为只写入/删除自己插入的测试行，不涉及任何他人数据。

#WorkBuddy# 用 WorkBuddy 给我自己的应用做安全体检：查出一个「匿名可写」的数据库权限漏洞

数据库

安全

后端

静态页加云数据库的应用中，公开key明文属正常，但需警惕RLS策略漏洞。实测发现匿名角色虽持有INSERT/UPDATE/DELETE权限，但RLS策略实际有效，因auth.uid()在未登录时返回'anon'，导致owner_id=auth.uid()条件自我满足，任何人可插入数据且管理员无法删除。修复方案为将写操作条件改为管理员UID白名单，并用INSERT返回码验证权限，避免误判。

2026上云采购 | AI焕新·智启新局

workbuddy

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

静态页加云数据库的应用中，公开key明文属正常，但需警惕RLS策略漏洞。实测发现匿名角色虽持有INSERT/UPDATE/DELETE权限，但RLS策略实际有效，因auth.uid()在未登录时返回'anon'，导致owner_id=auth.uid()条件自我满足，任何人可插入数据且管理员无法删除。修复方案为将写操作...

#WorkBuddy# 用 WorkBuddy 给我自己的应用做安全体检：查出一个「匿名可写」的数据库权限漏洞-腾讯云开发者社区-腾讯云

#WorkBuddy# 用 WorkBuddy 给我自己的应用做安全体检：查出一个「匿名可写」的数据库权限漏洞

#WorkBuddy# 用 WorkBuddy 给我自己的应用做安全体检：查出一个「匿名可写」的数据库权限漏洞

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐