Supabaseのセキュリティを確認するには｜RLS・DB関数・APIキーのレビュー項目

Supabaseの権限を確認するときは、RLSが有効かに加えて、利用者ごとの操作が意図どおりに制限されるかを試します。管理者・一般ユーザー・未ログインのそれぞれで操作を試してください。

この記事は、Supabaseを使ってサービスを試作した事業者・管理者向けです。本人が画面で確認できる操作と、技術担当者へ依頼する設定・処理の確認を分けます。自分が管理する環境とテストアカウントを用意し、顧客の実情報を使わずに試せる状態にしてください。

利用者と操作の組み合わせを表にする

たとえば、登録者が自分のプロフィールを編集するサービスなら、次のように期待する結果を書けます。これは説明用の例で、実際の要件に合わせて変えます。

追加・削除、所属組織、公開前の情報など、サービスで使う条件も加えます。この表を先に作ると、設定に正解を求める前に、何を守りたいのかが明確になります。

例：別の利用者には非公開情報を返さないか試す

自分のプロフィールだけを閲覧・編集できるサービスを想定します。検証用の利用者AとBを作り、Aのプロフィールに見分けられる架空の情報を登録します。確認する環境、対象の情報、期待する結果を技術担当者と共有してから試してください。

画面で操作を隠している場合は、画面の背後でデータを読み書きする処理も技術担当者が確かめます。Bの操作を試すときに管理者の強い権限を使うと、一般ユーザーの確認になりません。どの利用者の権限で試したかを記録してください。

結果には「Aでは表示できた」「Bへの応答にはAの情報が含まれなかった」など、確かめた事実を書きます。操作手順、期待する結果、実際の結果、確認者、確認日を一組で残します。試せなかった処理は未確認とし、技術者へ確認を依頼する項目にします。

RLSの条件は、操作ごとに読む

RLSはデータの行ごとにアクセスを制限する仕組みです。閲覧、追加、変更、削除の条件が、期待する操作と合うかを確認します。外部からアクセス可能な範囲とRLSの設定は、公式ガイドを参照してください。

閲覧・変更・追加には、それぞれ条件を設定できます。既存の行を変える条件と、新しい値を受け入れる条件も確認対象になります。

設定を変更したら、許可される操作と拒否される操作の両方をテストします。画面の操作だけでなく、その画面が呼ぶ処理も確認します。

DB関数とキーが持つ権限を確認する

データベース内の関数には、誰が実行でき、どの権限で動くかという設定があります。呼び出す人の想定と、実際のアクセス範囲が合っているかを点検します。Supabaseの関数ガイド

キーは種類を区別します。公開を想定したキーは、RLSなどのアクセス制御と組み合わせて使います。強い権限を持つ秘密のキーをブラウザへ配る構成にはできません。APIキーの公式ガイド

キーが見えたことだけを根拠に「すべて漏れている」と判断したり、キーを隠したことだけで点検を終えたりしないようにします。

テーブル以外の保存先とサーバー処理も対象にする

添付ファイルの保存先、サーバー側で実行する処理、外部APIへ渡す情報も確認します。テーブルの条件が正しくても、別の処理が利用者の確認をせずに情報を返していれば、意図した制限になりません。

ログには秘密情報や入力内容を必要以上に残さないようにします。アクセスできる担当者と保持する期間も、データ本体と別に確認します。

変更の履歴と、適用済みの状態を対応させる

AIにSQLを書いてもらう場合も、何を変え、どの環境で確認し、いつ本番へ適用したかを記録します。履歴ファイルがあることと、本番へ正しく反映されていることは別の確認です。

権限の変更後は、利用者の区分ごとのテストを繰り返します。結果と残課題を次の担当者が読める形で残してください。

レビュー全体の進め方はAI開発のセキュリティレビューガイド、依頼する範囲と費用は技術顧問の記事にまとめています。