在Supabase public schema存储敏感数据：仅靠RLS是否足够安全？

核心结论：只要RLS策略配置正确，公开schema的结构信息不会带来实质性安全风险，"通过模糊实现安全"在这里属于多余的做法。具体原因如下：

• RLS是底层强制防护，不受schema可见性影响
  RLS是Postgres内核级别的访问控制机制，只要你的tokens表策略严格限定"用户仅能访问自身数据"，任何不符合条件的请求（哪怕攻击者知道表名、字段结构）都会被Postgres直接拦截，根本无法读取或修改不属于自己的行数据。这才是数据安全的核心防线，schema结构的可见性不会突破这个防线。

• schema结构暴露的风险极低
  攻击者能获取的只是表名、字段名这类结构信息，除非你的字段命名直接包含极端敏感的业务逻辑（比如secret_user_bank_pin这种），否则常规的命名（比如tokens表的user_id、access_token）不会泄露额外机密。而且Supabase的API本身会验证用户身份并执行RLS策略，没有合法身份的请求连表的存在都无法试探出有效响应。

• 加密存储是额外安全层，和RLS互补
  你已经对第三方令牌做了加密存储，这是非常好的做法——就算出现极端情况（比如RLS策略临时失效），加密的数据也无法直接被利用，相当于给敏感数据加了双保险。

• 可选的优化（非必需）
  如果实在介意schema结构被公开，可以把敏感表迁移到非public的自定义schema，然后在Supabase控制台手动配置API权限，只允许暴露需要公开的schema。不过这属于额外的配置成本，从安全必要性来说不是必须的，因为RLS已经足够保障数据访问安全。

内容的提问来源于stack exchange，提问作者sundaycode