空のテーブルは安全に見える。データが入るまでは。

shipscan はコードと本番を両方読んで、RLS が無いのに空だから安全に見えるだけのテーブル——「偽の緑」——を公開前に見つけます。URL 専用スキャンには出せない指摘です。

GitHub リポジトリを繋ぐと確定検査(無料)。URL だけでもサクッとお試しできます。ただし「偽の緑」を見抜けるのは、コードを繋いだときだけ。
読み取り専用 · コードも結果も保存しません · トークンはその場で 1 回使うだけ、保存なし。

コード×本番 — 突き合わせると見えるもの

usersURL 専用スキャンでは検知できない偽の緑
コード RLS なし本番 0行(空)
profilesURL 専用スキャンでは検知できない矛盾
コード RLS 有効本番 1,240行 読める
orders保護済み
コード RLS 有効本番 0行

コードと本番を突き合わせて初めて見えるのが上の 2 つ:RLS が無いのに空だから安全に見えるテーブル(=「偽の緑」)と、コードでは「守ってる」のに実は全開のテーブル(=「矛盾」)。URL 専用はどっちも見逃します。

誰があなたのデータに届くか

チェックリストじゃなく到達グラフ。匿名の訪問者がどの守りを越えて、どのデータまで届くかを見せます。

✗ RLS✓ RLS匿名の訪問者usersorders
AI 製アプリのために
SupabaseLovableBoltCursorv0ReplitVercel
10件に1件監査された Lovable アプリが、匿名の訪問者に Supabase データを露出(CVE-2025-48757・10.3%)
既定で公開新しい Supabase テーブルは、RLS を有効にするまで anon キーで誰でも読めます
0行 ≠ 安全空のテーブルは守られて見えるだけ。Supabase 公式も「信じるな」と警告しています

出典: CVE-2025-48757 · Supabase docs

なぜ URL だけだと見逃すのか

空のテーブルと守られたテーブルは、外からは見分けがつきません——どちらも 0 行。RLS が本当に効いているかは、コードを見ないと分かりません。

ライブ検査で分かるのは「今」だけ。コードを見れば、次のデプロイも、staging も、作り直したあとも分かります。

Supabase 自身も言っています——「結果が空=安全」と思い込むな、と。

使い方

1

GitHub リポジトリを入れる

確定検査はリポジトリが起点(無料)。URL だけでもお試しできます。公開後に URL を足すと、code × live の突き合わせが効きます。

2

コード×本番を突き合わせ

migration を読んで、本番を実測して、横に並べます。

3

グラフと直し方が出る

誰がどのデータに届くかを図で。直し方も平易な手順つき。

チェックする範囲

他の vibe コーディング向けスキャナと同じ定番のチェックに加えて、コードと本番を突き合わせます。

対応バックエンドは今のところ Supabase だけ(ここは深く検査)。Firebase などの他バックエンドはまだ未対応で、検出はしますが中身までは見ていません。

匿名にデータを読まれないか

ログインしていない訪問者が、テーブル・ストレージ・RPC・ページに埋め込まれたデータに届かないか。

  • 初期HTML埋め込みデータ(__NEXT_DATA__)の露出初期 HTML(__NEXT_DATA__/SSR props)に埋まったデータは、ログインなしで誰でも読めます。
  • Supabase RLS の実測(テーブルを列挙し、ログインなしで読める件数を確認)匿名の訪問者として実際にテーブルを問い合わせ、ログインなしで読める行を確認します。
  • ログインなしで呼べるサーバ関数(RPC)の露出(定義のみ)ログインなしで呼べるサーバ関数は、権限チェックが無いと RLS を迂回します。
  • ログインなしで読める Supabase Storage(匿名の bucket/object 列挙)匿名の訪問者として bucket のオブジェクト一覧を試します。公開や設定漏れのバケットは誰でもファイルを読めます。
  • RLS の設定状況(migration/policy)migration/policy を読み、RLS が有効か・ポリシーがどう絞られているかを確認します。
  • 公開 Storage バケット公開 Storage バケットは、URL を知る誰もが全ファイルを読めます。
  • ログインなしで呼べる SECURITY DEFINER 関数SECURITY DEFINER 関数は定義者権限で動き、ログインなしで呼べると RLS を迂回します。

API ルートと認可は効いているか

守るべき API ルートや service-role 経路が、ログインなしで叩けてしまわないか。

  • 各ページ/API にログインなしで届くか(実測)各ページ/API を実際に叩き、本当にログインを要求するか(宣言だけでないか)を確認します。
  • 公開ルートの service_role 使用service_role は RLS を無視します。公開ルートで使うと全データが露出し得ます。
  • API ルートの認証要否API ルートがデータを返す前に認証を要求しているかを確認します。
  • ログイン済みユーザー間のアクセス(BOLA・Pro)Pro2 ユーザーのトークンで、ログイン済みユーザーが他人の行を読めるかを試します。

公開してはいけないものの露出

鍵・ソースマップ・設定ファイルなど、外に出してはいけないものが見えていないか。

  • 公開されたままの秘密ファイル(/.env, /.git)/.env や /.git が公開されていると、秘密やソース履歴がそのまま漏れます。
  • ソースコードが復元できる公開ファイル(source map)公開された .js.map があると、難読化していても誰でも元のソースを復元できます。
  • コミット済みの秘密(キー/トークン/秘密鍵)リポジトリにコミットされた鍵/トークンは、アクセスできる誰もが読め、ボットに素早く収集されます。

通信とハードニング

TLS・セキュリティヘッダ・配信経路など、土台が整っているか。

  • TLS/HTTPS(通信の暗号化)HTTPS が無いと、通信が途中で読まれたり改ざんされたりします。
  • セキュリティヘッダ(HSTS・CSP など)HSTS/CSP/X-Frame-Options が無いと、ダウングレード・インジェクション・クリックジャッキングに弱くなります。
  • CDN/エッジ検出アプリ前段の CDN/エッジを特定します(ヘッダやキャッシュの挙動に影響)。

依存ライブラリの既知脆弱性

lockfile の依存に、既知の脆弱性(CVE)が混じっていないか。

  • 使っているライブラリの既知の脆弱性(lockfile→OSV)lockfile にある既知の脆弱性(CVE)は調べやすく、悪用されやすいです。

攻撃面の把握(土台)

そもそもどのデータ・ルート・バックエンドに届きうるかを、まず洗い出す。

  • サイト内ページの巡回(1階層)アプリ自身のページを辿り、到達範囲の地図を作ります(以降の検査の土台)。
  • Supabase anon key 発見ページ内の公開 Supabase anon key を見つけます(匿名の訪問者がデータを問い合わせる入口)。
  • アプリが呼び出す API の発見フロントが呼ぶ API を洗い出し、ログインなしで何を返すか検査できるようにします。
  • アプリの外部接続先(バックエンド)の発見(CSP から)CSP から、アプリが接続する外部バックエンドを見つけます(考慮すべき別のデータ保管先)。
  • 同じドメインの別サイト発見(公開されている証明書の記録から)公開証明書ログから見つかる同ドメインの別ホストは、見直すべき追加の攻撃面です。

チェックしない

見ていない範囲:入力処理(インジェクション)・業務ロジック・サーバ内部の認可・ログ/監視。外からの自動チェックで見えない部分は、別途レビューが必要です。

料金

検出結果は無料。shipscan でお金がかかるのは「直し方」と「レポート出力」のロックを解除するときだけです。

無料
無料
アカウント不要

検出結果をすべて表示

  • 到達グラフ全体 — 誰がどのデータに、守りの層ごとに届くか
  • すべての検出結果 — 見るだけの検査・実測・コードとの突き合わせ・依存ライブラリ
  • 各リスクの「なぜ危険か」「放置すると」「照合した標準」
  • 検査する範囲・しない範囲を明示
無料で検査する →
準備中
Pro 月額
サブスク
サブスク・全プロジェクト

全プロジェクトで Pro・月額

  • Pro のすべて
  • 全プロジェクトで使える — 対象ごとの購入は不要
  • 直し方・レポート出力を、どの対象でも
  • 継続監視・変更の通知 — 未実装(準備中)
準備中

深い検査そのもの(実測・リポジトリ解析)は無料です——対象を所有しているか、検査の許可を得ていることの確認だけが必要です。お支払いでロックが解除されるのは、直し方の詳細とレポート出力です。Launch Pass は購入から30日間、同じ URL/リポジトリを何度でも再検査できるので、公開前に修正と再検査を繰り返せます。

よくある質問

他のスキャナと何が違う?
多くのスキャナは本番 URL だけを見ます。shipscan はリポジトリ(migration・コード)も読んで、両方を突き合わせる。だから「コードは守ってるのに本番は開いてる」「本番は緑だけどコードに守りが無い」を捕まえられます。URL 専用には出せない指摘です。
リポジトリは繋がないとダメ?
URL だけでもお試しはできます。ただ、コードを読むのが本体です——RLS や認可が実際に効いているかは、URL だけでは分かりません。なので確定検査には GitHub リポジトリが要ります。公開前はリポジトリだけでチェックでき、公開後に URL を足すと、コードと動いているアプリを突き合わせて各守りを実測で確定できます。
本番アプリに対して実行して大丈夫?
はい。検査は読み取りだけ。実測はあなたの同意のうえでだけ走り、データは書き込みません。
緑なら安全ってこと?
いいえ。「チェックした範囲では露出が見つからなかった」という意味です。入力処理・業務ロジック・サーバ内部の認可は、別途レビューが必要です。
コードやデータはどう扱われる?
検査は読み取り専用で、コードも結果も保存しません。渡したトークン(private リポジトリ用)は、その 1 回の検査だけに使い、保存しません。共有する結果には、あなたが公開を選んだ判定だけが入ります。

公開する前に、チェック

上の欄に GitHub リポジトリを入れる(URL だけのお試しでも OK)か、まずサンプルを見てください。

サンプル — 公開後に code×live(コードと実測)で確認して問題なしなら、この日付つき・検証できるバッジを貼れます(無料・合格証ではなく「チェックした記録」)。