SupabaseのData API公開設定が変更へ：新しいテーブルのGRANTとRLSを確認しよう

Supabaseが、既存プロジェクトにも新しい既定設定を適用すると案内している日が、10月30日だよ。変更後は、publicスキーマへ作った新しいテーブルをData APIから使うために、明示的な権限付与が必要になる。

4月28日に発表された変更の適用日を迎えたため、これからテーブルを増やす制作・運用での確認点を整理する。この記事は各プロジェクトの適用完了や、実際の障害発生を確認したものではないよ。自分の設定と作成手順を照合しよう。

既存テーブルが一斉に使えなくなる変更ではない

公式告知によると、既存テーブルは現在の権限を保つ。変更の中心は、新しく作るテーブルへData API用の権限を自動で付ける既定動作だよ。

スキーマは、データベース内のテーブルなどをまとめる名前空間。Data APIは、HTTP経由でデータを扱うSupabaseのREST・GraphQLの仕組みで、supabase-jsなどのクライアントも使っている。

一方、接続文字列を使ってPostgresへ直接接続するだけのアプリは、今回のData API公開設定の変更の影響を受けないと説明されている。同じデータベースでも、接続方法を分けて確認する必要があるね。

GRANTとRLSは別の役割

API保護の公式資料では、二つの層を分けている。

ロールはアクセス権を与える対象。代表的なものにanon、authenticated、service_roleがある。RLSはRow Level Securityの略で、行単位のアクセス制御を指すよ。

必要なGRANTがなければ、RLSのポリシーだけ整えてもAPIからテーブルを利用できない。逆に、GRANTを付けただけで、利用者ごとの行の制限が完成するわけでもないんだ。

新しいテーブルを作る流れを確認する

編集部としては、既存の公開設定を一括で広げる前に、次の順で確認することを勧める。

1. アプリがData API経由か、Postgresへの直接接続かを洗い出す。両方使っている場合は、対象の処理ごとに分ける。
2. テーブルを作るマイグレーションや自動化を確認する。マイグレーションは、構造の変更を管理するファイルや手順のこと。必要なロールと操作のGRANTが含まれるかを見る。
3. APIから公開する必要があるテーブルと、内部処理だけで使うテーブルを分ける。公開不要なものへ、エラーを消す目的だけで権限を付けない。
4. 開発用の環境で新規テーブル作成から確認し、意図したロールで必要な操作ができ、不要な操作や他人の行へアクセスできないことを確かめる。
5. 変更する権限とRLSをレビューし、既存の公開手順で反映する。権限を広げ過ぎた場合に、対象の変更を戻せるよう差分を残す。

SQL Editor、CLI、Management API、AIによる作成など、テーブルを作る経路だけを変えても、必要な権限付与の代わりにはならない。自動作成する仕組みでも、公開範囲を決める工程を含めよう。

permission deniedなら、まず不足している権限を読む

公式告知には、GRANTが不足している場合の例として、エラーコード42501と、対象テーブルの権限不足を示すメッセージが載っている。

実際にエラーが出たら、対象のテーブル、接続に使ったロール、必要な操作を確認しよう。ヒントに権限付与の例があっても、そのまま全テーブル・全ロールへ広げず、アプリの設計に必要な範囲へ絞ることが大切だよ。

このエラー例だけで、すべてのAPIエラーを今回の変更と判断することはできない。GRANTがそろっている場合は、RLS、認証状態、スキーマの公開設定なども別に確認してね。

関数やシーケンスは、同じ説明で済ませない

公式のセキュリティ資料は、テーブル、関数、シーケンスの既定権限の違いも説明している。特に、関数の実行権限にはPostgresのPUBLICへの既定権限が関係する。テーブルを自動公開しない設定にしただけで、関数も含めてすべて非公開になったとは判断しないようにしよう。

今回は、新しいテーブルのData API公開という疑問に絞って整理した。対象を広げる場合は、既定権限の説明まで確認し、オブジェクトの種類ごとに必要な権限を決めてね。

自動化で扱う設定値の置き場所には、GitHub ActionsのSecretsとVariablesも参考になるよ。データの公開権限と、接続情報の保管を分けて管理していこう。