Supabase で作ったアプリは、公開キーだけで何が読めるかを外から確かめる

Supabase の anon キー（新しい形式では publishable キー）はブラウザに埋め込まれる公開前提のキーで、守りは RLS（行レベルセキュリティ）だけ。AI に作らせたアプリは RLS が無効・甘いまま出ることがあり、テーブルの中身や書き込みまで外から通ってしまう。公開前に、そのキーだけで何ができるかを自分で試す。

どんな時に使う？

バイブコーディングで Supabase を使ったアプリを公開する前、公開した後
テーブルを AI に足させたあと（新しいテーブルで RLS を有効にし忘れる）

手順

ダッシュボードの Advisors（Security Advisor）を開き、「RLS が無効な public テーブル」などの警告をゼロにする
ブラウザの開発者ツールで、アプリが送っているプロジェクト URL と公開キーを確認する（外から見えるのはこれだけ）
ログインしていない状態を想定し、テーブルごとに読み取りを試す
bash
```
curl "https://<project>.supabase.co/rest/v1/<table>?select=*&limit=3" \
  -H "apikey: <公開キー>" -H "Authorization: Bearer <公開キー>"
```
行が返ってきたら、そのテーブルは誰でも読める。メールアドレス・電話番号・トークンのような列が入っていないか見る
書き込み（POST / PATCH / DELETE）も、捨てて良い環境で同様に試す
Storage のバケットが public になっていないか、認証の設定（メール確認の有無、サインアップを開けたままか）も確認する
直すときは、テーブルごとに enable row level security と、auth.uid() を使ったポリシーを AI に書かせ、上の確認をもう一度やる

注意点

service_role（secret）キーは RLS を素通りする。フロントエンドや公開リポジトリに入っていたら即ローテーション
確かめてよいのは自分が管理するプロジェクトだけ。他人のサイトに試すのは不正アクセスになりうる
@bani24884 は URL を入れるだけで、テーブルごとの読み書き可否・機密列の検出・設定を確認するツールを紹介していた（リンク先は短縮 URL のみで未確認）
フロントエンドの機械的なチェック全般は vlmkit: フロントの見た目の崩れを決定的に検出して、エージェントに直させる、脆弱性の一次チェックは E2E テストを OWASP ZAP 経由で流して、脆弱性の一次チェックにする

出典

X の投稿より: @bani24884 · 2026-02-26
Supabase ドキュメント（Row Level Security）: supabase.com