<aside> 📘

4.RLS設計におけるアンチパターンと注意点

</aside>

RLSは強力なセキュリティ機構ですが、その分「設計ミス」による事故も起こりうるものです。設計ミスはどんな天才でも一つのプロジェクトにかならず存在する人間の本質的問題です。だって設計ミスがなければ、何も進歩しないんですから。

ここでは、設計ミスを敵として考えるのではなく、よくありがちな設計ミス、うっかりやってしまった問題などの例でいくつか検討してみましょう。ここでは、RLSの設定でありがちな落とし穴（アンチパターン）と、それを避けるためのヒントをご紹介します。

アンチパターン1：ポリシーなし（RLSだけON）

ALTER TABLE messages ENABLE ROW LEVEL SECURITY;
-- ポリシーを作りません

この状態では、誰もデータにアクセスできない（全ブロック）状態になり、

「RLSが効いていないように見える」という混乱を生みます。

supabaseでRLSを有効にして、あとは何もしないという場合ですね。

ここが初心者の一番陥りやすいところですので、しっかり対策したいところです。

対策：必ず最低限のポリシーを設定しましょう。

アンチパターン2：USING (true) を乱用

CREATE POLICY "全員OK"
  ON messages
  FOR SELECT
  USING (true);

これは「誰でもアクセスOK」という意味です。テスト中によく使われますが、

本番で残っていると情報漏洩の原因になります！

対策：開発中に使った true ポリシーは本番前に必ず精査・削除しましょう。

アンチパターン3：auth.uid() の誤用

USING (user_id = auth.uid)