https://x.com/zeeg/status/2046251663909171489

RLS was a mistake and folks exposing that level of complexity to less technical users is asking for trouble. It was a mistake in Firebase. It’s a mistake in Supabase. It will be a mistake in the next product too. I personally - even knowing how to secure it - would never touch it. It’s the worst security footgun you can imagine. One small mistake and your data is available to the world.

のツイートを見つけて、(ツイートはやや強めな意見だったけれど)自分の考えをまた深めることができたのでよかった。

Supabaseの例でいうと、過去にこのような記事を書いていた。

https://www.ryusou.dev/unused-supabase-auth

ここではSupabase Authに着眼点をメインにおいて書いていたが、詰まるところRLSではセキュリティの誤設定の際の影響範囲が大きく、自分的には認証はMiddleware的な層で解決、認可レイヤーはアプリケーション側で処理するということを第一選択肢としたいと思っている。

Backendを書かずに済むことが価値になるケースもあるが、現代では

• Next.jsではAPI Route
• CloudflareであればCloudflare Workers

にAPIをデプロイして同様に簡単に書ける。

AppRouterなどから直接Supabaseを叩いたりすることも可能だが、そこは一つ抽象化する層として、API Routesを挟むのを必須とするのは認可ロジックをアプリケーション側に寄せることができる。

そうすると、ロジックに対してテストで制御してコントロールしやすくなるというメリットもあると思う。いわば設定側からコードに責務を移していると言えるだろう。

自分がSupabaseを使う場合は、DBをPublicに公開するのをやめて全てPrivateなスキーマとして扱う。これによってこの抽象化を必須とすることができる。PublicなスキーマをRLSで制御できると思うのはやめるようにしている。

RLSを使うということは、DBの認証機能つまるところSupabase Authが必要となる。必須というわけではないが、開発体験を最大限に享受しようとするとそのような設計になる。

逆にいえばPublicなスキーマに対してSupabase Authをセットで使わないと、設計・運用の難易度を考えると、高確率で事故につながりうると感じている。

Supabase Authを使うということは、Supabaseへの依存度が急激に高まることを意味する。私はSupabase Authをロックインとして捉えている(これは嫌な見方だという自覚はある)。

SupabaseのようなBaaSを使うときに人は口を揃えてMVPに最適というが、いくら設計でrepositoryなどを作ってSupabaseの依存を閉じ込めても何をしても、Supabase Authを使った瞬間にその依存を剥がす難易度は高まってしまう。

なのでそのようなデメリットがあること、構造的にロックインしてしまう構造になるということなどを考慮することで適切な技術選定ができると思う（もちろんこれはSupabaseに限った話ではない）。

そういった嫌な見方をしてメリット・デメリットを考えることが技術選定であると私は考えている。

こういうサービスへの見方はtoDeveloperなサービスをしているから培った感覚なのかもしれない....。

ちなみに私はSupabaseが好きでとても良い開発体験だなと思いながら使っている側の人間です。