権限の高いキーがフロントエンドに存在
service-role と secret キーは RLS を迂回するため、ブラウザへ配信してはいけません。
Supabase セキュリティ確認
ユーザーが実際に到達できる Supabase 境界を確認
公開クライアントキーと権限の高い秘密鍵を区別し、プロジェクトを確認できる場合に限定的な読み取り専用プローブを実行します。
ポリシー、ストレージ、認証、環境を変更した後や、実データ公開前に実行してください。
所有している、または明示的な許可を得たシステムのみをスキャンしてください。詳細エンジンには確認済みの許可が必要で、対象によっては利用できません。
レポート / 検出例例示
重大
レポート構成例
匿名リクエストでテーブル行を読み取り可能
- 根拠
- 公開クライアント文脈で上限付き読み取りがデータを返しました。保存する根拠は最小化します。
- 意味
- 観測された経路は、RLS が未設定または広すぎることを示します。
- 修正と検証
- RLS を有効化し、最小権限ポリシーを適用し、露出を確認して再検証してください。
これは説明用の検出例であり、お客様のアプリの結果ではありません。実際のレポートには、スキャナー、根拠の状態、対象ごとのカバレッジ制限が表示されます。
一般的なリスク経路
詳しく確認すべきポイント
これは Supabase プロジェクトに関連するリスクパターンであり、すべてのプロジェクトに問題があるという意味ではありません。根拠が得られた場合のみ検出として表示します。
匿名で行データを読み取り可能
未設定または広すぎるポリシーにより、公開APIからデータが露出します。
公開・列挙可能なストレージ
バケットやオブジェクトのポリシーにより、画面からリンクされていないファイルも露出します。
正直なカバレッジ
各スキャン面で証明できること
公開URL、接続済みソース、許可済み詳細エンジンはそれぞれ別の問いに答えます。BoringSec は根拠を分離し、部分的・ブロック・利用不可の状態を明示します。
公開メソドロジーを読む （英語）プロジェクトとキーの分類
対応URLを検出し、公開キーと権限の高い形式を区別します。
限定的なテーブルプローブ
上限付きの読み取りを行い、制限済み・脆弱・未確認・スキップを区別します。
ストレージ状態
オブジェクトの追加・変更・削除を行わず、限定的なバケット一覧動作を確認します。
不確実性を明示
アセット失敗、上限、拒否はカバレッジを下げ、合格には変換しません。
観測から検証まで
次の行動につながるレポート
- 01
観測
公開レスポンスを調べ、適用可能なバックグラウンドエンジンを開始します。
- 02
根拠を確認
何を、どのスキャナーが、どの確度で観測したかを確認します。
- 03
文脈に沿って修正
Supabase RLS に関係する文脈と具体的な修正手順を使います。
- 04
再テスト
新しい評価を実行し、その後のリグレッションは監視で検出します。
スキャン前の質問
Supabase の anon キーは漏えいした秘密情報ですか？
いいえ。公開クライアントキーは想定されたものです。RLS とストレージポリシーが境界です。
データベースを変更しますか？
いいえ。プローブは限定的かつ読み取り専用で、行やオブジェクトの追加・変更・削除を行いません。
すべての RLS ポリシーを証明できますか？
いいえ。観測できた経路のみです。認証ロールなどには許可された文脈が必要です。
問題なしなら Supabase は安全ですか？
いいえ。部分的、ブロック、利用不可のカバレッジは明示されます。
公開アプリを確認し、すべての修正を検証
まず公開URLから開始し、必要な場合にのみソースや認証済みコンテキストを追加します。
セキュリティスキャンを開始