hacktricks-cloud/src/pentesting-ci-cd/supabase-security.md

Supabase セキュリティ

{{#include ../banners/hacktricks-training.md}}

基本情報

公式のlanding pageによると：Supabase はオープンソースの Firebase 代替です。プロジェクトは Postgres データベース、Authentication、instant APIs、Edge Functions、Realtime subscriptions、Storage、Vector embeddings で開始できます。

サブドメイン

基本的にプロジェクトが作成されると、ユーザーは次のような supabase.co サブドメインを受け取ります：jnanozjdybtpqgcwhdiz.supabase.co

Database configuration

Tip

This data can be accessed from a link like https://supabase.com/dashboard/project/<project-id>/settings/database

この database はいずれかの AWS リージョンにデプロイされ、接続するには次のように接続できます：postgres://postgres.jnanozjdybtpqgcwhdiz:[YOUR-PASSWORD]@aws-0-us-west-1.pooler.supabase.com:5432/postgres（これは us-west-1 に作成されました）。
パスワードはユーザーが事前に設定した password です。

したがって、サブドメインが既知でユーザー名として使われ、AWS のリージョンが限られているため、brute force the password を試みることが可能かもしれません。

このセクションでは次のオプションもあります：

• Reset the database password
• Configure connection pooling
• Configure SSL: Reject plan-text connections (by default they are enabled)
• Configure Disk size
• Apply network restrictions and bans

API Configuration

Tip

This data can be accessed from a link like https://supabase.com/dashboard/project/<project-id>/settings/api

プロジェクトの supabase API にアクセスする URL は次のようになります：https://jnanozjdybtpqgcwhdiz.supabase.co。

anon api keys

また、role: "anon" のような anon API key を生成します。例：eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6ImFub24iLCJpYXQiOjE3MTQ5OTI3MTksImV4cCI6MjAzMDU2ODcxOX0.sRN0iMGM5J741pXav7UxeChyqBE9_Z-T0tLA9Zehvqk — アプリケーションはこの API key を使用して API にアクセスする必要があります。

この API に接続するための REST API は docs で確認できますが、最も興味深いエンドポイントは次のとおりです：

Signup (/auth/v1/signup)

``` POST /auth/v1/signup HTTP/2 Host: id.io.net Content-Length: 90 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>

<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>

So, whenever you discover a client using supabase with the subdomain they were granted (it's possible that a subdomain of the company has a CNAME over their supabase subdomain), you might try to **create a new account in the platform using the supabase API**.

### シークレット / service_role APIキー

A secret API key will also be generated with **`role: "service_role"`**. This API key should be secret because it will be able to bypass **Row Level Security**.

The API key looks like this: `eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJzdXBhYmFzZSIsInJlZiI6ImpuYW5vemRyb2J0cHFnY3doZGl6Iiwicm9sZSI6InNlcnZpY2Vfcm9sZSIsImlhdCI6MTcxNDk5MjcxOSwiZXhwIjoyMDMwNTY4NzE5fQ.0a8fHGp3N_GiPq0y0dwfs06ywd-zhTwsm486Tha7354`

### JWTシークレット

A **JWT Secret** will also be generate so the application can **create and sign custom JWT tokens**.

## 認証

### サインアップ

> [!TIP]
> **デフォルトでは** supabase は前述の API エンドポイントを使用して、**新しいユーザーがアカウントを作成すること**を許可します。

However, these new accounts, by default, **will need to validate their email address** to be able to login into the account. It's possible to enable **「匿名サインインを許可」** to allow people to login without verifying their email address. This could grant access to **unexpected data** (they get the roles `public` and `authenticated`).\
This is a very bad idea because supabase charges per active user so people could create users and login and supabase will charge for those:

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

#### Auth: サーバー側のサインアップ制御

Hiding the signup button in the frontend is not enough. If the **Auth server still allows signups**, an attacker can call the API directly with the public `anon` key and create arbitrary users.

Quick test (from an unauthenticated client):
```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

Expected hardening:

• Disable email/password signups in the Dashboard: Authentication → Providers → Email → Disable sign ups (invite-only), or set the equivalent GoTrue setting.
• Verify the API now returns 4xx to the previous call and no new user is created.
• If you rely on invites or SSO, ensure all other providers are disabled unless explicitly needed.

RLS and Views: Write bypass via PostgREST

Using a Postgres VIEW to “hide” sensitive columns and exposing it via PostgREST can change how privileges are evaluated. In PostgreSQL:

• Ordinary views execute with the privileges of the view owner by default (definer semantics). In PG ≥15 you can opt into security_invoker.
• Row Level Security (RLS) applies on base tables. Table owners bypass RLS unless FORCE ROW LEVEL SECURITY is set on the table.
• Updatable views can accept INSERT/UPDATE/DELETE that are then applied to the base table. Without WITH CHECK OPTION, writes that don’t match the view predicate may still succeed.

Risk pattern observed in the wild:

• A reduced-column view is exposed through Supabase REST and granted to anon/authenticated.
• PostgREST allows DML on the updatable view and the operation is evaluated with the view owner’s privileges, effectively bypassing the intended RLS policies on the base table.
• Result: low-privileged clients can mass-edit rows (e.g., profile bios/avatars) they should not be able to modify.

Illustrative write via view (attempted from a public client):

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>"

ビューと RLS のハードニングチェックリスト:

• ベーステーブルを公開する場合は、明示的で最小権限の付与と正確な RLS ポリシーを優先する。
• どうしてもビューを公開する必要がある場合：
• 更新不可にする（例: 式/結合 を含める）か、すべての信頼できないロールに対してビューへの INSERT/UPDATE/DELETE を拒否する。
• 呼び出し元の権限がオーナーの権限ではなく使用されるように ALTER VIEW <v> SET (security_invoker = on) を適用する。
• ベーステーブルでは ALTER TABLE <t> FORCE ROW LEVEL SECURITY; を使用し、オーナーであっても RLS の適用対象とする。
• 更新可能なビュー経由で書き込みを許可する場合、WITH [LOCAL|CASCADED] CHECK OPTION とベーステーブル側の補完的な RLS を追加して、許可された行のみが書き込まれ/変更されることを保証する。
• Supabase では、end-to-end の挙動をテストで検証していない限り、ビューに対して anon/authenticated に書き込み権限を付与しない。

検出のヒント:

• anon と authenticated のテストユーザーから、公開されているすべてのテーブル/ビューに対してすべての CRUD 操作を試みる。拒否されるべき箇所で書き込みが成功した場合、それは設定ミスを示す。

OpenAPI駆動の CRUD プロービング (anon/auth ロールから)

PostgREST は OpenAPI ドキュメントを公開しており、それを使ってすべての REST リソースを列挙し、低権限ロールから許可された操作を自動的にプローブすることができる。

OpenAPI を取得する（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 に組み込む。
• 公開されている table/view/function はすべて第一級のサーフェスとして扱う。view が基底テーブルと同じ RLS のポスチャを“継承”すると仮定しない。

Passwords & sessions

最小パスワード長（デフォルト）、要件（デフォルトではなし）、および leaked passwords の使用を禁止する設定が可能です。
デフォルトの要件は弱いため、要件を強化することを推奨します。

• User Sessions: ユーザーセッションの動作（タイムアウト、ユーザーごとに 1 セッションなど）を設定可能です。
• Bot and Abuse Protection: Captcha を有効にできます。

SMTP Settings

メール送信のための SMTP を設定可能です。

Advanced Settings

• access tokens の有効期限を設定する（デフォルト 3600）
• 潜在的に侵害された refresh tokens を検出して取り消すよう設定およびタイムアウトを設定する
• MFA: ユーザーごとに同時に登録できる MFA 要素数を指定する（デフォルト 10）
• Max Direct Database Connections: 認証に使用される最大接続数（デフォルト 10）
• Max Request Duration: Auth リクエストが許容される最大時間（デフォルト 10 秒）

Storage

Tip

Supabase は ファイルを保存 し、URL 経由でアクセス可能にできます（S3 バケットを使用）。

• アップロードファイルサイズの上限を設定する（デフォルト 50MB）
• S3 接続は次のような URL で提供されます: https://jnanozjdybtpqgcwhdiz.supabase.co/storage/v1/s3
• S3 access key を リクエスト でき、access key ID（例: a37d96544d82ba90057e0e06131d0a7b）と secret access key（例: 58420818223133077c2cec6712a4f909aec93b4daeedae205aa8e30d5a860628）で構成されます。

Edge Functions

supabase にも secrets を保存 でき、それらは edge functions からアクセス可能 です（Web から作成・削除はできるが、値を直接参照することはできません）。

References

• 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

{{#include ../banners/hacktricks-training.md}}