本文详解如何通过 rls 策略 + 合理数据建模，在 supabase 中安全实现用户交互式操作（如虚拟鼓掌），杜绝前端恶意请求篡改计数，兼顾安全性与可扩展性。
本文详解如何通过 rls 策略 + 合理数据建模，在 supabase 中安全实现用户交互式操作（如虚拟鼓掌），杜绝前端恶意请求篡改计数，兼顾安全性与可扩展性。
在构建用户参与型功能（例如“鼓掌”“点赞”“收藏”）时，仅依赖客户端身份认证（如 signInWithPassword）和简单的 RLS 读写控制是远远不够的。正如你所观察到的：即使启用了“仅限认证用户更新”的 RLS 策略，攻击者仍可通过浏览器控制台或 Postman 复用有效的 Authorization Bearer Token 和 apikey，反复发送伪造的 UPDATE 请求，无限刷高计数——这本质上是缺乏操作原子性、状态校验与行为约束所致。
关键在于：不要直接更新计数字段（如 claps_count INT），而应记录每一次真实发生的用户行为事件。换言之，将“鼓掌”建模为一个不可变的、带上下文的原子操作（即插入一条记录），再通过聚合查询获取最终计数。这种设计天然支持防刷、限频、去重、审计与数据分析。
✅ 推荐方案：事件表 + 强约束 RLS
首先创建 claps 表，记录每次鼓掌的完整上下文：
-- 创建鼓掌事件表（主键为 (post_id, user_id)，天然防止重复鼓掌）
create table if not exists public.claps (
post_id uuid references public.posts on delete cascade not null,
user_id uuid references auth.users on delete cascade not null,
created_at timestamp with time zone default timezone('utc'::text, now()) not null,
PRIMARY KEY (post_id, user_id) -- 关键：联合主键确保单用户对单内容仅能鼓掌一次
);
-- 启用行级安全
alter table public.claps enable row level security;
-- 允许所有认证用户查询（如获取某文章总鼓掌数）
create policy "Anyone can read claps"
on claps for select
using ( true );
-- 仅允许用户为自己插入鼓掌记录（且不能伪造 user_id）
create policy "Users can insert their own clap"
on claps for insert
with check ( auth.uid() = user_id );? 为什么有效？
- INSERT 操作受 with check (auth.uid() = user_id) 严格约束：即使请求携带了其他用户的 user_id，Supabase 也会拒绝该行插入；
- 联合主键 (post_id, user_id) 保证幂等性：重复提交同一用户的同一内容鼓掌请求会因主键冲突而静默失败（返回 409 Conflict），无需额外逻辑；
- 所有历史鼓掌均被持久化，便于后续实现「每24小时限10次」「同一IP/设备限频」等策略（只需扩展 RLS 或添加数据库函数）。
? 安全读取计数（前端/服务端调用）
不再维护冗余的 claps_count 字段，而是实时聚合：
// Supabase Client（TypeScript 示例）
const { count, error } = await supabase
.from('claps')
.select('*', { count: 'exact', head: true })
.eq('post_id', 'your-post-uuid');
if (error) throw error;
console.log(`当前鼓掌数：${count}`); // 安全、准确、无竞态? 提示：对高频访问场景，可配合数据库物化视图或应用层缓存（如 Redis）提升性能，但数据源始终以 claps 表为准，保障一致性。
⚠️ 重要注意事项
- 禁用 UPDATE / DELETE 权限：除非业务强需求（如“取消鼓掌”），否则不应开放对 claps 表的修改权限。若需撤回，建议新增 is_active BOOLEAN DEFAULT true 字段并用 UPDATE ... SET is_active = false 实现软删除，同时在 RLS 中加入 is_active 过滤。
- 避免 JWT 短期失效“取巧”方案：将 token 过期设为 1 秒虽能限制重放窗口，但会严重破坏用户体验（频繁重登录）、增加服务端负载，且无法阻止同一秒内的多次请求。这不是安全加固，而是掩盖设计缺陷。
-
补充防护（进阶）：
- 在 RLS 中加入时间约束（如 created_at > now() - interval '1 second'）防范明显的时间戳篡改（需客户端时间可信度较高）；
- 结合 Supabase Edge Functions 做前置风控（如验证 reCAPTCHA、检查设备指纹、限流）；
- 对敏感操作启用 auth.aud 校验或自定义 JWT claim（如 role: 'user'），增强策略粒度。
✅ 总结
安全的鼓掌功能 = 事件驱动建模 + 严格 RLS + 幂等性保障。它不依赖前端信任，不妥协用户体验，也不牺牲可审计性。你放弃的是“直接 UPDATE 计数”的简单，换来的是可防御、可演进、符合现代 Web 安全范式的坚实基础。从今天起，让每一次鼓掌，都成为数据库里一条不可篡改、不可抵赖的真实记录。
