Supabaseに関するよくある勘違い
2023年頃から注目を浴び続けているSupabase。
様々な記事で目にするSupabaseに関する勘違いが多く含まれているので、自分自身の整理も兼ねて記事を投稿します。
過去に投稿した内容と重複していますが、Supabaseに触れた人が必ずやらかしてしまう問題だと思っているので注意喚起として定期的に同じ内容を投稿しています！
勘違い（１） Supabaseを使えばバックエンドは不要！ ← そんな訳がない
100%の間違いではありませんが、おおよそ間違いです。
これは僕も勘違いしていたことですが、Supabaseを使うときは結局自前のバックエンドの処理が必要です。もちろん、フロントエンドだけでの実装は可能です。しかし、現実問題としてセキュリティ的な懸念が多く、フロントエンドのみの実装は逆に特殊なガードをする必要があるため、無駄な工数が増えてしまいます。
ポリシー設定は適切にやらないと危ない
また、ポリシーと呼ばれるPostgreSQLの設定をミスしてしまうだけで、テーブル単位でデータを盗まれかねない重大な問題が起きる恐れがあります。ポリシーとは、設定した条件でTRUEに該当するリクエストの場合だけデータを返してくれる仕組みです。
ポリシーは正しく理解しないとかなり危険です。
例えば、ユーザーが投稿したデータを全員に見せてあげたいからと TRUE とだけで設定していまうと、そのテーブル全体が全て丸見えの状態になります。（URLパラメータを変更するだけでWHERE句とか様々な条件を添えて実行できてしまう。）そのため、スクレイピングの際にDBの生データを自由な条件で収集されてしまったり、テーブルにコピーしたユーザーのメールアドレスや住所など、様々な見えてはいけないデータが第三者に見られてしまう可能性があります。
RLSのポリシー設定ミスによるセキュリティインシデントの事例
実際のサービスで僕が見つけて指摘した重大なインシデントの事例があります。
無料で使い放題の生成系AIで、ユーザーが入力したプロンプトとその回答が丸見えになっていたり、本来非公開なはずのユーザーのメールアドレスが見えたり...というヤバい状態のものがありました。幸いなことに住所などの個人を直接的に特定できるデータは含まれていなかったため、それほど大きな問題ではありませんが、これに住所が含まれていたら...と考えるとゾッとしますよね。（あまりにもマズイものを見つけてしまった感があり理性が働いた結果、どんなデータが含まれていたかは詳しく見ていないのでご安心ください。）
この指摘により現在のリートンではSupabaseの採用を取りやめてしまったようです...。悲しい...。
※結構大きい内容だったので、指摘したら何かもらえるのかな～って期待してましたが何も無くちょっと残念。笑（本件について守秘義務的な契約を結んでいないですし、ニュースリリースが出てしますので記事投稿しても問題無いという認識です。）
▼当時のニュースリリース
この問題の対策
このような問題を起こさないためにも、
- バックエンドの介入を検討する。（それでもポリシーの設定は適切に。Next.jsで実装する例としては、API Routesで service role key を使ってsupabaseクライアントを作り、RLS設定で service_role権限 のオペレーションをtrueにする形でよろしいかと思います。）
- どうしてもフロントエンドだけで実装したいならば、
.rpc()を経由してデータを取得するように変更する。.rpc()を使うことでデータ取得範囲を自分で制御できるようにしておくということですね。 - Postman等で各テーブルにリクエストを投げてデータ流出しないかをチェックしておく。
上記のどれでも結構ですので取り入れてみてください。
参考になりそうな記事をいくつか投稿してありますのでご覧いただければと思います。
たったこれだけでも安全に利用できるので過度に恐れる必要はありません。僕はSupabaseが大好きで個人開発でも使っています！
とはいえ、フロントエンドだけの処理でもSNSっぽいサービスを作ることは可能です！（かなり大変でした！）既にクローズしちゃいましたが過去にSNSっぽいサービスをバックエンド処理ほぼ無しで作ったことがあります。
勘違い（２）Supabaseは簡単！ ← 想像するほどは簡単ではない
触りの部分だけ見るととても簡単に使えそうなイメージですが、ちゃんと使っていくとなると意外とそうでもないかもしれない、という印象なります。
Supabaseはまだまだ情報が少ないです。
何か問題が起きると自分で解決しなければならないシーンも多いです。
個人的に意味が分からないのが Next.js + Supabase をローカル開発する際の OAuth処理 です。Supabase CLIで1年ぐらい前のバージョンから localhost ではなく、127.0.0.1 に変更されました。その影響で Next.jsが標準で立ち上がる localhost と Supabase の 127.0.0.1 とのギャップができてしまい、そのままでは無設定では開発を進められないという点です。（Next.jsで127.0.0.1:3000 でアクセスすればいいのですがこれを毎回打つのも面倒なのでlocalhost派です。）
この問題によってOAuth処理がlocalhostとしては完了せず、127.0.0.1に飛ばされてしまいます。Next.jsで開発する方はlocalhostで進めたいでしょうから、スムーズな開発とは行きません。
恐らくアプリ開発等も考慮しての変更かと思いますが、Next.js向けのドキュメントに一切書かれておらず、問題になりそうな箇所を自分で見つけて、自分で解決しなければなりません。
▼この問題に関する記事を書きました。
勘違い（３）サインアップのときにユーザー情報を public.users テーブルにコピーする必要がある ← 場合によっては必要だが、ユーザー交流しないサービスならコピー不要
今はこの認識は正しくありません。
数年前でしたらこの認識は正しかったかと思います。（僕も実際にサインアップの際にトリガーしてコピーするということをしていましたし、Supabase公式が動画で解説していたり、僕もZenn記事を書いたことがあります。）
現在では、auth.users の raw_user_meta_data にユーザーが編集し得るデータ（紹介文、メールアドレスなど）を入れたり、 raw_app_meta_data にはサブスク契約プラン（webhookや他システムなどのユーザーが触れないところからのデータ挿入）を入れる流れになっているようです。
※ raw_user_meta_data は supabase.auth.signUpのoptions から追加できる。raw_app_meta_dataは管理者権限級の supabase.auth.admin.updateUserById から編集できる。app_metadataの方はサインアップのタイミングでは無理っぽい。
勘違い（４）ローカル環境が重すぎてお話にならない。←これはガチだけど回避策がある
Supabaseのローカル環境は Docker 上で動くのですが、10個ほどコンテナが立ち上がります。これがかなり重たくて何も工夫しないとPCのファンが回りまくってかなり熱くなります。正直なところ、快適な開発環境とは全く言えないレベルです。
この状況を改善する方法はあります。物理的なマシンがもう一つ必要にはなりますが、リバースプロキシを通すだけで簡単な方法で劇的に改善するのでぜひ検討してみてください。
おしまい
Supabaseは触りの部分はかなり簡単です。少し踏み込んだことをやろうとするとハードルがグッと上がります。（不具合があったり情報収集の面で。）
過去にはOAuthしたユーザー名に @ が含まれていると正常に処理が完了しない、などの気づきにくい問題が含まれていたこともあります。
Supabaseは開発スピードが爆速なため、少し前の情報が古くなることも多いです。こういった小さな問題がいくつも連なって結構きついという印象も感じています。
ですが、全体的には素晴らしい開発体験なので今後も永く使っていきたいと考えています。
みなさんもぜひZennで日本語で情報を発信して頂けると嬉しいです！僕もガンガンSupabaseの情報を今後も発信していきます！
Discussion