跳转至

Supabase 2025 年度安全回顾

文章背景与核心概要

2025 年，Supabase 将工作重心转向构建更安全的平台默认设置，并提供更强大的工具，旨在降低开发者使用 Postgres 行级安全性（RLS）及整体数据库安全功能的门槛。本文回顾了 2025 年推出的关键安全特性，包括 API 密钥模型的重构、自动化的 RLS 执行机制、AI 驱动的安全顾问以及强化的漏洞披露计划。

此外，本文还概述了 2026 年的安全加固路线图。通过这些改进，Supabase 致力于在提升开发效率的同时，确保从项目创建之初即具备企业级的安全防护能力，从而有效降低数据泄露和配置错误的风险。

1. API 与架构控制

创建项目时禁用 Data API

新项目现在可以完全禁用 Data API，或者将默认架构从 public 更改为自定义架构（如 api）。这使您可以精细控制通过自动生成的 REST 和 GraphQL API 暴露的内容。

New projects can disable the Data API entirely or change the default schema from public to a custom schema like api. This gives you granular control over what is exposed via the auto-generated REST and GraphQL APIs.

在现有项目中禁用 Data API

现有项目可以直接在项目设置中禁用 Data API。禁用后，您可以像使用标准 Postgres（类似于 AWS RDS）一样继续使用数据库，通过直接连接或连接池进行访问。

Existing projects can disable the Data API directly in their project settings. Once disabled, you can continue to use the database like standard Postgres (similar to AWS RDS), connecting either directly or through the connection pooler.

2. 身份验证与密钥管理

新型 API 密钥

新的 API 密钥模型取代了基于 JWT 的长效 anon 和 service_role 密钥。项目现在使用 publishable（可发布）密钥进行低权限访问，并使用多个可撤销的 secret（机密）密钥进行高权限访问。密钥可以即时轮换、审计，并进行更细粒度的作用域限制，从而改善轮换和审计工作流。旧版密钥在迁移期间仍然可用，但将在 2026 年底移除。

The new API key model replaces long-lived JWT-based anon and service_role keys. Projects now use publishable keys for low-privilege access and multiple revocable secret keys for elevated access. Keys can be rotated instantly, audited, and scoped more granularly to improve workflows around rotation and auditing. Legacy keys remain available during migration but will be removed in late 2026.

非对称 JWT

新的 API 密钥系统支持非对称 JWT（使用私钥签名，公钥验证）。与共享密钥相比，这实现了更安全的密钥分发和轮换，降低了签名密钥泄露带来的整体影响。

The new API key system supports asymmetric JWTs (signed with private keys, verified with public keys). This enables safer key distribution and rotation compared to shared secrets, reducing the overall impact if a signing key is compromised.

通过 GitHub Secret Scanning 撤销泄露密钥

借助新的 API 密钥格式，Supabase 会自动撤销在公共 GitHub 存储库中检测到的机密密钥。一旦检测到泄露，密钥将立即被撤销，并通知项目所有者，同时提供如何轮换密钥的说明。

With the new API key formats, Supabase automatically revokes secret keys detected in public GitHub repositories. When a leak is detected, the key is immediately revoked, and the project owner is notified with instructions on how to rotate it.

使用 Publishable 密钥限制 OpenAPI 规范

使用新的 publishable 密钥时，OpenAPI 规范不再公开可见。此前，任何拥有 anon 密钥的人都可以查看您的完整 API 架构，包括所有表和列。使用 publishable 密钥后，OpenAPI 规范需要提升权限才能访问，从而防止未经授权的架构枚举并减少信息泄露。

The OpenAPI spec is no longer publicly visible when using the new publishable keys. Previously, anyone with an anon key could view your complete API schema, including all tables and columns. With publishable keys, the OpenAPI spec requires elevated permissions, preventing unauthorized schema enumeration and reducing information disclosure.

3. 行级安全性 (RLS) 与访问控制

新表默认启用 RLS

对于通过仪表板创建的表，RLS 默认处于启用状态。表从创建之初就受到保护，遵循“默认安全”原则。

For tables created via the dashboard, RLS is enabled by default. Tables are protected from the moment they are created, following the principle of secure-by-default.

创建表时自动启用 RLS

如果您使用不启用 RLS 的外部工具或迁移脚本创建表，可以使用 Postgres 事件触发器（Event Triggers）自动强制执行 RLS。Supabase 在 2025 年向平台添加了事件触发器，并记录了如何为任何表创建方法设置自动 RLS 执行，同时在仪表板中添加了一键设置功能。

If you create tables using external tools or migrations that do not enable RLS, you can use Postgres Event Triggers to enforce RLS automatically. Supabase added Event Triggers to the platform in 2025, documented how to set up automatic RLS enforcement for any table creation method, and added a one-click setup in the dashboard.

表暴露时的清晰标签

表编辑器现在会为任何禁用 RLS 的表显示清晰的警告标签，使您可以立即识别哪些表在没有行级安全策略的情况下通过 API 暴露。

The Table Editor now shows a clear warning label for any table that has RLS disabled, making it immediately obvious which tables are exposed via the API without row-level security policies.

针对无 RLS 表的安全警报

如果您创建了任何禁用 RLS 的表，Supabase 会向项目所有者发送电子邮件警报。这些警报也会出现在仪表板中，方便您在部署到生产环境之前识别并保护这些表。

If you create any tables with RLS disabled, Supabase sends email alerts to project owners. These alerts also appear in the dashboard, making it easy to identify and secure tables before deploying to production.

列级安全性

Postgres 支持列级权限，可限制对表中特定列的访问（对于社会安全号码、薪资或其他个人身份信息等敏感数据非常有用）。您可以授予表的 SELECT 访问权限，同时排除特定列，这样除非用户拥有明确的列访问权限，否则这些列不会出现在 API 响应或查询中。这与 RLS 独立运行并可协同工作。

Postgres supports column-level privileges that restrict access to specific columns in a table (useful for sensitive data like SSNs, salaries, or other PII). You can grant SELECT access to a table while excluding specific columns so they do not appear in API responses or queries unless the user has explicit column access. This works independently of—and alongside—RLS.

自定义声明与 RBAC

自定义声明允许您向 JWT 添加元数据以实现基于角色的访问控制（RBAC）。无需为每个表编写 RLS 策略，您可以将角色信息嵌入身份验证令牌中，并在策略内进行评估。

Custom claims let you add metadata to JWTs for role-based access control (RBAC). Instead of writing RLS policies for each table, you can embed role information in the authentication token and evaluate it within your policies.

4. 安全工具与 AI 辅助

安全顾问 (Security Advisors)

安全顾问使用 Splinter（一个用于 Postgres 的开源安全检查工具）扫描您的项目是否存在配置错误。顾问会检查常见模式，例如未启用 RLS 的表、权限过大的策略以及暴露的敏感列。组织所有者会收到每周摘要邮件，所有检测到的问题都会在仪表板中显示，并提供修复建议。

Security Advisors scan your project for misconfigurations using Splinter, an open-source security linter for Postgres. Advisors check for common patterns such as tables without RLS, overly permissive policies, and exposed sensitive columns. Organization owners receive weekly summary emails, and all detected issues are visible in the dashboard with recommended fixes.

使用 AI 修复安全问题

仪表板包含一个助手，可帮助修复安全顾问检测到的安全问题。您可以要求助手以纯文本形式生成并应用 RLS 策略、建议配置改进，并更快速地编写正确的策略。安全顾问也可通过我们的 MCP 服务器使用，允许开发者直接从本地开发环境扫描并修复问题。

The dashboard includes an Assistant that helps fix security issues detected by Security Advisors. You can ask the Assistant to generate and apply RLS policies in plain text, suggest configuration improvements, and write correct policies more quickly. Security Advisors are also available through our MCP server, allowing developers to scan and fix issues directly from their local development environment.

5. 网络与基础设施安全

PrivateLink 将您的 VPC 直接连接到 Supabase 基础设施，无需经过公共互联网，从而减少了攻击面并改善了延迟。它可以直接在仪表板的项目设置中启用。

PrivateLink connects your VPC directly to Supabase infrastructure without traversing the public internet, reducing the attack surface and improving latency. It can be enabled directly from project settings in the dashboard.

限制对 Postgres 数据库的直接访问

所有 Supabase 数据库都运行 fail2ban，在多次登录失败后自动阻止 IP 地址。您还可以配置 IP 允许列表，将数据库访问限制为特定的受信任地址。

All Supabase databases run fail2ban to automatically block IP addresses after multiple failed login attempts. You can also configure IP allowlists to restrict database access to specific trusted addresses.

6. 漏洞披露与研究人员参与

Supabase 通过红队（对抗性和非预告）和紫队（协作性）参与，利用外部研究人员进行持续的安全测试。

除了定期测试外，Supabase 还在 HackerOne 上运营一个活跃的漏洞披露计划（VDP）： * 当前规模： 自发布以来，已解决来自 96 位研究人员的 139 份报告（过去 90 天内收到 42 份报告）。 * 响应目标： * 首次响应：2 个工作日（中位数 8 小时） * 分类（Triage）：5 个工作日（中位数 10 小时） * 解决：视严重程度而定（中位数 2 天） * 范围： 平台基础设施、PostgREST 暴露、身份验证流程、服务角色隔离、实时订阅、存储访问控制、边缘函数和网络分段。 * 认可： 目前仅提供认可；付费赏金计划将于 2026 年推出，并根据严重程度和影响进行分级。

Supabase runs continuous security testing using external researchers through red team (adversarial and unannounced) and purple team (collaborative) engagements.

In addition to scheduled testing, Supabase operates an active Vulnerability Disclosure Program (VDP) on HackerOne: * Current Volume: 139 reports resolved from 96 researchers since launch (42 reports received in the last 90 days). * Response Targets: * First response: 2 business days (median 8 hours) * Triage: 5 business days (median 10 hours) * Resolution: Severity-dependent (median 2 days) * Scope: Platform infrastructure, PostgREST exposure, auth flows, service role isolation, Realtime subscriptions, Storage access controls, Edge Functions, and network segmentation. * Recognition: Currently recognition-only; paid bounties will launch in 2026 scaled by severity and impact.

7. 2026 年展望

未来一年计划进行几项重大的安全改进：

  • 暴露架构的授权切换： 一种新的 UI 控件，可直接从仪表板一键切换单个表的 API 访问权限，无需手动执行 SQL 授权语句（目前处于暂存阶段）。
  • 替代授权模式： 探索与 OpenFGA 和 Zanzibar 等授权系统的集成，以及改进社区构建扩展（如 supabase_rbac）的扩展文档和仪表板集成。
  • GitHub 推送保护： 与 GitHub 合作，添加推送保护，在包含机密密钥的提交到达存储库之前将其拦截。
  • 默认禁用 GraphQL： pg_graphql 在新项目中将默认禁用，以最大限度地减少默认攻击面。
  • 扩展安全顾问检查： 向 Splinter 添加新的检查项，以检测弱密码策略、过度的函数权限和不安全的扩展配置。
  • 加固项目配置： 新的项目配置选项允许开发者选择进入极度加固的安全环境，同时扩展“自带云服务”（Bring Your Own Cloud）产品。
  • 安全测试工具： 一个专门的测试工具，帮助开发者在生产部署前验证 RLS 策略和授权逻辑。
  • 全方位助手： 将仪表板助手直接集成到 GitHub、Slack 和电子邮件安全建议等工作流中。
  • 增强的安全警报： 在警报中提供更详细的影响说明、分步修复指南和内联代码示例。

Several major security improvements are planned for the upcoming year:

  • Grant Toggles for Exposed Schemas: A new UI control to toggle API access for individual tables directly from the dashboard with a single click, bypassing the need for manual SQL grant statements (currently in staging).
  • Alternative Authorization Patterns: Exploring integrations with authorization systems like OpenFGA and Zanzibar, along with improved extension documentation and dashboard integration for community-built extensions like supabase_rbac.
  • GitHub Push Protection: Collaborating with GitHub to add push protection to block commits containing secret keys before they reach the repository.
  • GraphQL Disabled by Default: pg_graphql will be disabled by default on new projects to minimize the default attack surface.
  • Expanded Security Advisor Lints: Adding new checks to Splinter to detect weak password policies, excessive function privileges, and insecure extension configurations.
  • Hardened Project Configurations: New project configuration options allowing developers to opt into extremely hardened security environments, alongside an expanded "Bring Your Own Cloud" offering.
  • Security-Focused Test Harness: A dedicated test harness to help developers validate RLS policies and authorization logic prior to production deployment.
  • Assistant Everywhere: Integrating the dashboard Assistant directly into workflows like GitHub, Slack, and email security recommendations.
  • Enhanced Security Alerts: Providing more detailed explanations of impact, step-by-step remediation guidance, and inline code examples within alerts.