行级安全性是保护其数据的 Supabase 项目与悄悄暴露数据的项目之间的界限。当 RLS 配置正确时，您的数据库会在行级别强制执行受 RLS 约束的角色的访问规则。特权角色（包括服务角色）可以绕过这些规则。如果配置不当，表看起来会受到保护，而策略会允许更多内容通过。
本文比较了运行 Supabase RLS 安全检查的两种方法：手动验证策略和运行自动 RLS 审核。两者都有一席之地。了解每个问题的出处是验证数据库访问策略是否按预期工作的方法。
行级安全性如何工作以及策略悄然出错的地方
RLS 是 Supabase 按表公开的 Postgres 功能。一旦启用，表将拒绝受 RLS 约束的角色的行访问，除非策略允许；具有旁路权限的表所有者和角色是例外。策略根据当前用户、他们的声明以及正在运行的查询进行评估。的 auth.uid() 功能通常是锚点：类似的策略 using (auth.uid() = user_id) 限制对登录用户自己的数据库行的访问。
模型很干净。失败则不然，因为它们很少看起来像失败。
一些模式可以解释大多数 RLS 问题：
RLS 在某些表上启用，但并非全部。 启动后添加的新表或通过迁移创建的表可以在 RLS 关闭的情况下发货。然后，具有表访问权限的任何角色都可以读取每一行。
一项比其字面上更广泛的政策。
using (true)在选择策略上意味着每一行都是可见的。很容易在开发过程中为了调试而添加而忘记删除。服务角色无处不在。 使用服务角色密钥的服务器端代码完全绕过 RLS。如果面向用户的请求通过该密钥运行，则策略永远不会适用。
检查错误列的策略。
auth.uid() = id在桌子上id是行的主键，而不是所有者，永远不会匹配意图。该策略存在，它返回错误或空集，并且表面仍然有效。没有适当的访问控制的数据库更新和删除。 开发人员通常会彻底保护选择并宽松地保留写入策略。通过读取检查并没有说明谁可以接下来修改该行。
这些都没有自行宣布。每个人都保持应用程序正常运行，这正是他们能够生存到生产环境的原因。
进行手动 RLS 审核：要检查的内容以及漏掉的错误
手动审核是直接的，不需要新工具。您可以逐个表地研究策略本身。
首先列出每个表并确认每个表上都启用了 RLS。然后，对于每个表，枚举策略并将它们映射到预期的访问：谁应该读取，谁应该写入，以及谁不应该触摸它。根据其比较的列读取每个策略表达式。确认选择、插入、更新和删除均具有与预期角色匹配的策略。
接下来，检查代码路径。确定您的应用程序实际使用哪个密钥来处理面向用户的请求，以及其中是否有任何密钥通过服务角色运行。然后以不同的用户身份编写测试查询并确认结果符合预期：用户应该读取自己的行而不是其他人的行，并且不应该能够更新他们不拥有的行。
人工审核是值得做的，而且能收获很多。它还具有可预测的盲点。
它测试您记得要测试的内容。 如果您不想以第二个用户身份尝试删除，则可能会错过过于宽泛的删除策略。启用 RLS 后，没有适用的删除策略意味着删除被拒绝。
它老化了。 随着功能的添加，策略也会发生变化。上个季度进行的彻底审查没有提及您上周添加的表格。
这取决于配置策略的同一个人。 制定政策的建筑商最不可能发现自己的假设。
它需要有记录的证据。 “我检查了它，它看起来不错”没有留下任何东西：没有证据，没有范围，没有您可以稍后重新扫描的工件。
手动审核回答了“这符合我的系统思维模型吗？”的问题。它本身并不能证明数据库实际返回的内容。
运行自动 RLS 检查并根据结果采取行动
自动 Supabase RLS 安全检查从另一个方向进行。它以攻击者或配置错误的客户端的方式执行项目，并报告数据层实际允许的内容。
这种转变很重要，原因有三个。首先，它扩展了过去的内存：扫描重复检查其配置范围内可用的表和端点。如果没有适当的访问权限，外部扫描无法检查每个策略。其次，它会生成您可以采取行动的证据：结果命名了表、策略状态以及使其可访问的条件，以便您知道要更改什么以及为什么要更改。第三，它是可重复的。您可以再次运行的检查将一次性审核转变为持续验证。
VICE 扫描 Web 应用程序和 Supabase/RLS 配置，然后报告结果及其背后的证据和纠正指导。您可以标记修复并请求重新检查，但只有类似的重新扫描才能确认问题已解决：修复是针对相同范围进行验证的，而不是从编辑中假设的。计划扫描和警报支持持续监控，因此下个月添加的表不会悄悄地重新引入差距。
分工很简单。运行自动检查以查找手动审核遗漏的内容，然后使用手动传递来确认扫描标记的每个策略背后的意图。自动化告诉您数据库允许什么；您可以决定该许可是否是故意的。
任何扫描的分数描述了测试范围，但不能保证项目完全安全。将其视为查看位置的信号，而不是证书。
您应该使用哪种方法？
如果您正在部署使用 Supabase 构建的产品并且从未审核过您的策略，那么诚实的答案是，按顺序两者都是。从自动 RLS 检查开始，以便您对表所允许的内容有一个最新的、有证据支持的图片。然后手动检查发现的结果，确认每项政策的意图，并修复那些偏离的政策。将自动检查安排在计划中，以便新表和新策略得到与原始表和新策略相同的审查。
跳过任何一种方法都可能导致数据库访问策略看似保护数据，但仍然允许未经授权的访问。
开始免费扫描 注册前请访问vice-platform.com，查看您的公共网站。专门的 Supabase 扫描需要经过验证的域名和付费订阅或购买的积分；其覆盖范围取决于配置的访问。
