Feedbase 安全架构深度解析RLS 行级安全与双权限 API 密钥体系【免费下载链接】feedbaseThe open-source solution for collecting feedback communicating updates.项目地址: https://gitcode.com/gh_mirrors/fe/feedbaseFeedbase 是一款开源的产品反馈收集与更新沟通解决方案它把用户反馈和更新日志两大高频场景做成了开箱即用的 SaaS 形态。很多开发者关心的是这样一个直接面向公网、允许匿名用户提交反馈的系统安全架构到底靠什么撑起来答案就藏在两层设计里——数据库底层的RLS 行级安全以及应用层的双权限 API 密钥体系。这篇文章将用最通俗的方式带你拆解 Feedbase 的安全纵深设计理解它如何做到公开可读、严格可控。一、先认识 Feedbase 的数据地基Feedbase 基于 SupabasePostgreSQL构建几乎所有业务数据——反馈、评论、更新日志、项目配置、成员关系——都存放在一张张数据库表中。它的数据库结构定义在 supabase/migrations/20231126133700_db_auth_schema.sql 中包括changelogs、feedback、feedback_comments、profiles、projects、project_members等核心表。对于一个允许任何人浏览反馈、匿名提交想法的产品来说最大的安全悖论是数据既要对外公开又不能被随意篡改。Feedbase 的解法是让 PostgreSQL 的 RLSRow Level Security行级安全成为第一道、也是最硬的一道防线。二、RLS 行级安全数据库层面的隐形门卫什么是 RLS为什么要用它传统 Web 应用往往在应用层做权限判断数据库本身来者不拒。RLS 的思路完全不同在数据库内部对每一行数据设置访问规则。即使你的应用代码出了 bug、密钥泄露甚至遭遇 SQL 注入数据库也会在返回数据前强制校验越权查询直接返回空结果。Feedbase 在迁移脚本中为每一张业务表都执行了ALTER TABLE ... ENABLE ROW LEVEL SECURITY这意味着没有一条数据能绕过规则被读取。Feedbase 的 RLS 策略组合拳Feedbase 的权限策略遵循一套清晰的读公开、写认证原则操作类型默认策略典型对象SELECT读取对所有人开放反馈、更新日志、标签等INSERT写入仅登录用户反馈、评论、项目等UPDATE / DELETE仅登录用户项目、配置、邀请等特别值得一提的是profiles用户资料表它的策略更加严格用户可以读取所有人的资料但只能更新自己的那一行通过auth.uid() id校验。这就是 RLS 最优雅的地方——用数据库原生能力把最小权限落实到每一行数据。双重认证API 密钥也能过 RLS 关卡在 supabase/migrations/20231130182016_api_key_system.sql 中Feedbase 定义了一个SECURITY DEFINER函数is_allowed_api_token()它会从请求头中读取lumkey字段与project_api_keys表中的 token 比对。所有核心表如changelogs、projects、project_configs的 RLS 策略都会调用这个函数来放行合法的 API 请求。换句话说API 密钥认证不是应用层的锦上添花而是直接嵌入数据库策略的刚性约束。即使攻击者伪造请求只要没有合法 token数据库这一关就过不去。三、双权限 API 密钥体系一把钥匙开一扇门如果说 RLS 是地基那么 API 密钥体系就是门锁系统。Feedbase 用一枚简单的枚举实现了非常实用的权限分级。Full Access 与 Public Access两种权限怎么选API 密钥的权限类型定义在迁移脚本开头的token_type枚举中只有两种取值full_access完全访问管理员级别可以读写项目下的所有资源——更新日志、项目配置、成员、邀请、API 密钥本身几乎等同于项目主人的操作权限。public_access公共访问受限权限主要用于提交反馈等面向公网的操作例如向feedback表插入新反馈。选择建议很简单给后端服务、CI/CD、自动化脚本用 Full Access给前端页面、公开提交反馈的小程序用 Public Access。这样即使前端密钥被扒走攻击者也无法篡改你的更新日志或项目配置。密钥的一生生成、展示与阅后即焚Feedbase 对密钥的生命周期管理相当考究相关逻辑在 apps/web/lib/utils.ts 和 apps/web/lib/api/projects.ts 中生成调用generateApiToken(fb, 20)生成以fb_开头、后接 20 位随机字符的 token格式清晰且熵值足够高。展示一次创建密钥的弹窗见 apps/web/components/dashboard/modals/add-api-key-modal.tsx会明确提示 Keep this key safe. You will not be able to view it again!——完整 token 仅在创建瞬间展示关闭后无法再次查看。脱敏存储查询密钥列表时后端只返回short_token完整 token 的前 12 位用于 UI 展示和身份识别完整 token 永远不回传前端。数量限制每个项目最多创建 3 个 API 密钥且名称不可重复避免密钥泛滥失控。四、一次请求的通关之旅认证链路全流程Feedbase 的双权限密钥是如何从请求头一路验证到数据库的完整链路清晰而严密客户端在 HTTP 请求的Authorization头中以Bearer token形式携带密钥后端在 apps/web/lib/auth.ts 的createClient()中截取 token并将其注入到发往 Supabase 请求的lumkey头中Supabase 侧执行 SQL 时RLS 策略调用is_allowed_api_token()校验lumkey是否匹配、权限类型是否符合应用层还会二次核对该密钥是否属于当前项目防止跨项目盗用并判断public_access密钥是否越权访问了仅限 Full Access 的资源全部通过后数据才被放行返回。这套应用层前置校验 数据库 RLS 兜底的双保险正是 Feedbase 安全架构的精髓。公开的 API 路由如 apps/web/app/api/v1/[slug]/changelogs/route.ts读取更新日志时走allowAnonAccess通道而写入类操作则必须持有合法密钥完美兼顾了公开与安全。五、给开发者的三条安全实践建议看完 Feedbase 的安全设计你可以直接把这套思路迁移到自己的项目中善用 RLS 做兜底哪怕应用层权限写得再严也一定要在数据库层开启 RLS把最后一道门焊死。权限分级而非一刀切参考 Full Access / Public Access 的二元模型让不同场景使用不同密钥缩小攻击面。密钥脱敏与限流完整密钥只展示一次、列表只返回短标识、限制密钥数量——这些看似微小的细节能极大降低泄露风险。结语Feedbase 用 RLS 行级安全筑牢数据底座用双权限 API 密钥体系实现精细管控再通过密钥阅后即焚短标识脱敏项目级隔离等设计补全细节。对于想自建反馈收集系统的团队来说这套开源的安全架构不仅可靠更是一份值得逐行研读的安全教科书。如果你也正在构建类似的多租户 SaaS不妨直接阅读上文提到的迁移脚本与认证源码把这份成熟经验抄进自己的项目里。【免费下载链接】feedbaseThe open-source solution for collecting feedback communicating updates.项目地址: https://gitcode.com/gh_mirrors/fe/feedbase创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考