{“email”:“test@exmaple.com”,“password”:“SomeCOmplexPwd239.”}

</details>

<details>

<summary>登录 (/auth/v1/token?grant_type=password)</summary>

POST /auth/v1/token?grant_type=password HTTP/2 Host: hypzbtgspjkludjcnjxl.supabase.co Content-Length: 80 X-Client-Info: supabase-js-web/2.39.2 Sec-Ch-Ua: “Not-A.Brand”;v=“99”, “Chromium”;v=“124” Sec-Ch-Ua-Mobile: ?0 Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6ImFub24iLCJpYXQiOjE3MTQ5OTI3MTksImV4cCI6MjAzMDU2ODcxOX0.sRN0iMGM5J741pXav7UxeChyqBE9_Z-T0tLA9Zehvqk User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/124.0.6367.60 Safari/537.36 Content-Type: application/json;charset=UTF-8 Apikey: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6ImFub24iLCJpYXQiOjE3MTQ5OTI3MTksImV4cCI6MjAzMDU2ODcxOX0.sRN0iMGM5J741pXav7UxeChyqBE9_Z-T0tLA9Zehvqk Sec-Ch-Ua-Platform: “macOS” Accept: / Origin: https://cloud.io.net Sec-Fetch-Site: same-site Sec-Fetch-Mode: cors Sec-Fetch-Dest: empty Referer: https://cloud.io.net/ Accept-Encoding: gzip, deflate, br Accept-Language: en-GB,en-US;q=0.9,en;q=0.8 Priority: u=1, i

{“email”:“test@exmaple.com”,“password”:“SomeCOmplexPwd239.”}

</details>

因此，每当你发现客户在使用 supabase 且使用了他们被授予的子域（公司某个子域可能对他们的 supabase 子域设置了 CNAME），你可以尝试 **使用 supabase API 在平台上创建一个新账户**。

### secret / service_role API 密钥

还会生成一个带有 **`role: "service_role"`** 的 secret API key。这个 API 密钥应该保密，因为它能绕过 **Row Level Security**。

API 密钥看起来像这样： `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6InNlcnZpY2Vfcm9sZSIsImlhdCI6MTcxNDk5MjcxOSwiZXhwIjoyMDMwNTY4NzE5fQ.0a8fHGp3N_GiPq0y0dwfs06ywd-zhTwsm486Tha7354`

### JWT Secret

还会生成一个 **JWT Secret**，以便应用可以 **创建并签署自定义 JWT tokens**。

## 身份验证

### 注册

> [!TIP]
> 默认情况下，supabase 将允许 **新用户通过前面提到的 API 端点在你的项目上创建账号**。

但是，这些新账户默认情况下**需要验证他们的电子邮件地址**才能登录。可以启用 **"Allow anonymous sign-ins"** 以允许用户在不验证邮箱的情况下登录。这可能会授予对**意外数据**的访问（他们会获得 `public` 和 `authenticated` 角色）。\
这是非常糟糕的做法，因为 supabase 按活跃用户收费，所以人们可以创建用户并登录，supabase 会对这些用户收费：

<figure><img src="../images/image (1) (1) (1) (1) (1) (1).png" alt=""><figcaption></figcaption></figure>

#### Auth: 服务器端注册强制执行

仅在前端隐藏注册按钮并不足够。如果 **Auth server 仍然允许注册**，攻击者可以使用公共的 `anon` key 直接调用 API 并创建任意用户。

快速测试（来自未认证的客户端）：
```bash
curl -X POST \
-H "apikey: <SUPABASE_ANON_KEY>" \
-H "Authorization: Bearer <SUPABASE_ANON_KEY>" \
-H "Content-Type: application/json" \
-d '{"email":"attacker@example.com","password":"Sup3rStr0ng!"}' \
https://<PROJECT_REF>.supabase.co/auth/v1/signup

预期的加固措施：

• 在 Dashboard 中禁用电子邮件/密码注册：Authentication → Providers → Email → Disable sign ups (invite-only)，或设置等效的 GoTrue setting。
• 验证 API 现在对之前的调用返回 4xx，并且没有创建新用户。
• 如果依赖邀请或 SSO，确保所有其他 providers 被禁用，除非明确需要。

RLS and Views: Write bypass via PostgREST

使用 Postgres VIEW 来“隐藏”敏感列并通过 PostgREST 暴露，可能会改变权限的评估方式。在 PostgreSQL：

• 普通视图默认以视图所有者的权限执行（definer semantics）。在 PG ≥15 中可以选择使用 security_invoker。
• Row Level Security (RLS) 作用于基表。表所有者会绕过 RLS，除非在表上设置了 FORCE ROW LEVEL SECURITY。
• 可更新视图可以接受 INSERT/UPDATE/DELETE，这些操作随后应用到基表。没有 WITH CHECK OPTION 的情况下，不符合视图谓词的写入可能仍然成功。

在实战中观察到的风险模式：

• 一个列被减少的视图通过 Supabase REST 暴露并授予给 anon/authenticated。
• PostgREST 允许对可更新视图进行 DML，且该操作以视图所有者的权限进行评估，从而有效地绕过基表上原本的 RLS 策略。
• 结果：低权限客户端可以批量编辑他们不应修改的行（例如 profile bios/avatars）。

示例：通过视图进行的写操作（从公共客户端尝试）：

curl -X PATCH \
-H "apikey: <SUPABASE_ANON_KEY>" \
-H "Authorization: Bearer <SUPABASE_ANON_KEY>" \
-H "Content-Type: application/json" \
-H "Prefer: return=representation" \
-d '{"bio":"pwned","avatar_url":"https://i.example/pwn.png"}' \
"https://<PROJECT_REF>.supabase.co/rest/v1/users_view?id=eq.<victim_user_id>"

Hardening checklist for views and RLS:

• 优先公开基础表，并使用明确的最小权限授权和精确的 RLS 策略。
• If you must expose a view:
• 如果必须公开 view：
• Make it non-updatable (e.g., include expressions/joins) or deny INSERT/UPDATE/DELETE on the view to all untrusted roles.
• 使其不可更新（例如，包含表达式/连接），或对所有不受信任的角色拒绝 INSERT/UPDATE/DELETE 对该 view 的操作。
• Enforce ALTER VIEW <v> SET (security_invoker = on) so the invoker’s privileges are used instead of the owner’s.
• 强制使用 ALTER VIEW <v> SET (security_invoker = on)，以便使用调用者的权限而不是所有者的权限。
• On base tables, use ALTER TABLE <t> FORCE ROW LEVEL SECURITY; so even owners are subject to RLS.
• 在基础表上使用 ALTER TABLE <t> FORCE ROW LEVEL SECURITY;，这样即使是所有者也会受到 RLS 约束。
• If allowing writes via an updatable view, add WITH [LOCAL|CASCADED] CHECK OPTION and complementary RLS on base tables to ensure only allowed rows can be written/changed.
• 如果通过可更新的 view 允许写入，添加 WITH [LOCAL|CASCADED] CHECK OPTION 并在基础表上配套设置 RLS，以确保只能写入/修改被允许的行。
• In Supabase, avoid granting anon/authenticated any write privileges on views unless you have verified end-to-end behavior with tests.
• 在 Supabase 中，除非通过测试验证了端到端行为，否则不要授予 anon/authenticated 对 view 的任何写权限。

Detection tip:

• 检测提示：
• From anon and an authenticated test user, attempt all CRUD operations against every exposed table/view. Any successful write where you expected denial indicates a misconfiguration.
• 使用 anon 和 authenticated 测试用户，对每个公开的表/视图尝试所有 CRUD 操作。任何本应被拒绝但实际成功的写操作都表明存在配置错误。

OpenAPI-driven CRUD probing from anon/auth roles

PostgREST exposes an OpenAPI document that you can use to enumerate all REST resources, then automatically probe allowed operations from low-privileged roles.

PostgREST 会暴露一个 OpenAPI 文档，可用于枚举所有 REST 资源，然后自动探测低权限角色允许的操作。

Fetch the OpenAPI (works with the public anon key):

curl -s https://<PROJECT_REF>.supabase.co/rest/v1/ \
-H "apikey: <SUPABASE_ANON_KEY>" \
-H "Authorization: Bearer <SUPABASE_ANON_KEY>" \
-H "Accept: application/openapi+json" | jq '.paths | keys[]'

探测模式（示例）:

• 读取单行（根据 RLS 预期返回 401/403/200）：

curl -s "https://<PROJECT_REF>.supabase.co/rest/v1/<table>?select=*&limit=1" \
-H "apikey: <SUPABASE_ANON_KEY>" \
-H "Authorization: Bearer <SUPABASE_ANON_KEY>"

• 测试 UPDATE 被阻止（使用不存在的 filter 来避免在测试期间更改数据）：

curl -i -X PATCH \
-H "apikey: <SUPABASE_ANON_KEY>" \
-H "Authorization: Bearer <SUPABASE_ANON_KEY>" \
-H "Content-Type: application/json" \
-H "Prefer: return=minimal" \
-d '{"__probe":true}' \
"https://<PROJECT_REF>.supabase.co/rest/v1/<table_or_view>?id=eq.00000000-0000-0000-0000-000000000000"

• 测试 INSERT 被阻止:

curl -i -X POST \
-H "apikey: <SUPABASE_ANON_KEY>" \
-H "Authorization: Bearer <SUPABASE_ANON_KEY>" \
-H "Content-Type: application/json" \
-H "Prefer: return=minimal" \
-d '{"__probe":true}' \
"https://<PROJECT_REF>.supabase.co/rest/v1/<table_or_view>"

• 测试 DELETE 被阻止：

curl -i -X DELETE \
-H "apikey: <SUPABASE_ANON_KEY>" \
-H "Authorization: Bearer <SUPABASE_ANON_KEY>" \
"https://<PROJECT_REF>.supabase.co/rest/v1/<table_or_view>?id=eq.00000000-0000-0000-0000-000000000000"

Recommendations:

• 将之前的探测针对 anon 和最低权限的 authenticated 用户自动化，并将其集成到 CI 中以捕捉回归。
• 将每个暴露的 表/视图/函数 视为一级攻击面。不要假设视图会“继承”其基表相同的 RLS 姿态。

密码与会话

可以指定最小密码长度（默认）、密码要求（默认没有）并禁止使用 leaked passwords。
建议 改进默认的密码要求，因为默认设置较弱。

• User Sessions: 可以配置用户会话的工作方式（超时、每个用户 1 个会话…）
• Bot and Abuse Protection: 可以启用 Captcha。

SMTP Settings

可以设置 SMTP 来发送邮件。

高级设置

• 设置访问令牌的过期时间（默认 3600）
• 设置以检测并撤销可能被妥协的 refresh tokens 并设置超时
• MFA：指定每个用户一次可注册多少 MFA 因子（默认 10）
• Max Direct Database Connections：用于 auth 的最大直接数据库连接数（默认 10）
• Max Request Duration：Auth 请求允许的最长时间（默认 10s）

存储

Tip

Supabase allows to store files and make them accesible over a URL (it uses S3 buckets).

• 设置上传文件大小限制（默认 50MB）
• The S3 connection is given with a URL like: https://jnanozjdybtpqgcwhdiz.supabase.co/storage/v1/s3
• 可以 request S3 access key，由 access key ID（例如 a37d96544d82ba90057e0e06131d0a7b）和 secret access key（例如 58420818223133077c2cec6712a4f909aec93b4daeedae205aa8e30d5a860628）组成

Edge Functions

可以在 supabase 中 store secrets，这些 secrets 将被 accessible by edge functions（可以通过 web 创建和删除，但无法直接获取其值）。

参考资料

• Building Hacker Communities: Bug Bounty Village, getDisclosed’s Supabase Misconfig, and the LHE Squad (Ep. 133) – YouTube
• Critical Thinking Podcast – Episode 133 page
• Supabase: Row Level Security (RLS)
• PostgreSQL: Row Security Policies
• PostgreSQL: CREATE VIEW (security_invoker, check option)
• PostgREST: OpenAPI documentation

Tip

学习并练习 AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
学习并练习 GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
学习并练习 Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

支持 HackTricks

• 查看 subscription plans!
• 加入 💬 Discord group 或者 telegram group 或 关注 我们的 Twitter 🐦 @hacktricks_live.
• 通过向 HackTricks 和 HackTricks Cloud github 仓库 提交 PRs 来分享 hacking tricks。