Hacker News 中文摘要

RSS订阅

关闭RLS后，您的Supabase将公开可见 -- Your Supabase is public if you turn off RLS

原文链接 | HN讨论 | 2025-12-23 11:02:05

文章摘要

文章指出许多开发者在使用Supabase时未正确设置安全措施，导致数据库URL和匿名密钥直接暴露在前端代码中。攻击者只需简单检查网络请求或发送curl命令，就能获取完整的数据库访问权限，甚至包括初创公司的敏感数据。作者已多次发现此类问题，呼吁开发者重视安全配置。

文章总结

你的Supabase数据库可能正暴露在公众视野中

一位开发者在检查朋友新开发的SaaS项目时，发现了一个常见的安全隐患：通过简单的网络检查就能获取Supabase的URL和匿名密钥(anon key)。这种情况已经是他第三次遇到了，其中还包括一家种子轮初创公司。

【安全隐患】 - 开发者只需使用curl命令就能获取OpenAPI架构信息 - 更严重的是，通过检查用户表端点，往往能直接获取包含用户名、昵称、邮箱、密码哈希等敏感信息的完整JSON数据

【问题根源】 1. 开发者创建了额外的公共用户表 2. 没有设置适当的行级安全策略(RLS) 3. 匿名密钥本应公开，但不当使用会导致其成为整个数据库的"万能钥匙"

【解决方案建议】 - Supabase应该在创建用户表时弹出显著警告 - 可以参考Pocketbase的做法：默认设置完善的访问控制，如id = @request.auth.id检查 - 系统设计应该从根本上预防此类安全隐患

【现状担忧】 以Lovable平台为例，每天创建超过10万个项目，其中有多少存在数据库暴露风险？虽然可以归咎于用户技能不足，但系统设计者也应承担责任。

（注：文中图片链接和社交媒体图标等非核心内容已省略）

评论总结

以下是评论内容的总结：

  1. Supabase安全性问题的主要原因是开发者操作不当

    • 开发者常绕过安全控制，将数据放在Public模式而不启用RLS（行级安全）
      "unskilled developers bypass those controls out of convenience and put data into Public without RLS" (anxman)
      "people just really do not comprehend what the 'public' schema means" (jscheel)
    • Supabase默认是安全的，但需要开发者正确配置
      "The default is secure... You have to go out of your way with Supabase" (mediaman)
      "Supabase is pretty good at warning you about these things" (PierceJoy)

  2. 类似问题在其他平台（如Firebase）也存在

    • 开发者常忽略权限设置
      "Firebase seems to suffer a similar problem of people not setting permissions right" (int0x29)
      "Amateur devs have been doing this for a decade with Firebase" (devmor)
    • 一体化平台易让开发者忽视安全性
      "they tend to lure people into a sense of 'wow this is easy to use' such that they forget to check security" (dangoodmanUT)

  3. 对Supabase的批评与辩护

    • 批评：Supabase吸引缺乏经验的开发者
      "attracts people who have NO IDEA what they’re doing" (stephenlf)
      "if your product targeting 'dummy user' they should make it dummy foolproof" (tonyhart7)
    • 辩护：Supabase已提供充分警告和默认安全设置
      "it does actually warn you constantly if you don't set up RLS" (giogio)
      "the default is to turn on RLS for new tables" (mediaman)

  4. 替代方案建议

    • 自托管PostgreSQL或其他传统架构
      "A simple springboot Java app... will last a long time" (k4rli)
      "stop using all these Vercel-likes... self hosting PostgreSQL" (koakuma-chan)
    • 完全禁用不必要的功能
      "Turn off the REST API... Disable the JWT/anon token(s)" (dmillar)

  5. 其他技术讨论

    • RLS存在潜在漏洞
      "There are known timing attacks against it" (awitt)
    • Anon密钥的性质争议
      "Isn't Supabase anon key actually a publishable one?" (pranavm27)

总结：评论普遍认为Supabase的安全问题主要源于开发者误用，而非平台本身的设计缺陷，但对其是否应进一步简化安全配置存在分歧。类似问题在其他一体化平台（如Firebase）中同样存在，部分用户建议回归传统架构以提升安全性。