Supabase uygulamalarının Row Level Security açıkken bile veri sızdırdığı yedi yol

dev.to'da yayınlanan bir yazı, bir Supabase uygulamasının Row Level Security (RLS) etkinleştirildikten sonra bile bir kullanıcının verisini başka bir kullanıcıya açığa çıkarabileceği yedi somut yolu katalogluyor. Yazarın temel iddiası şu: dashboard'daki yeşil "RLS enabled" göstergesi yanlış bir güven duyusu yaratıyor; RLS'yi etkinleştirmek yalnızca tabloyu bu mekanizmanın bir parçası yapar, kimin gerçekte neyi gördüğüne ise policy'ler, view'lar, grant'lar ve çevredeki özellikler karar verir.

Yazıya göre tipik senaryo şudur: geliştirici RLS'yi açar, tek bir policy yazar, kendi hesabıyla test eder ve boşluğu ancak bir kullanıcı başkasının faturasını gördüğünü bildirdiğinde fark eder.

Verinin hâlâ sızdığı yedi yüzey

1. Fiilen açık policy'ler. RLS etkin ama hiç policy'si olmayan bir tablo, service role dışında herkesi engeller — bozuk ama sızma değil. Asıl tehlikeli durum, çoğunlukla for select using (true) gibi geliştirme aşamasından kalma bir kural ya da public veya anon rolüne verilmiş izin verici bir policy'dir. Anon key istemci paketine gömülüdür ve herkes tarafından görülebildiğinden, böyle bir policy tabloyu tüm dünyaya okunur hale getirir. Önerilen çözüm, okumaları sahipliğe göre sınırlandırmaktır; örneğin auth.uid() = user_id.

2. Yazma işlemlerinde eksik WITH CHECK. USING, bir kullanıcının hangi satırları okuyabileceğini, güncelleyebileceğini veya silebileceğini; WITH CHECK ise ne ekleyebileceğini veya değiştirebileceğini belirler. WITH CHECK içermeyen bir INSERT veya UPDATE policy'si, okumayı kullanıcının kendi satırlarıyla sınırlarken, kullanıcıya başka bir workspace'in veya organizasyonun ID'siyle etiketlenmiş satırlar yazma imkânı tanıyabilir.

3. RLS'yi baypas eden view'lar. Standart bir Postgres view'ı, sahibinin ayrıcalıklarıyla çalışır ve tablonun RLS'sini uygulamaz; bu yüzden kullanıcı özeti gibi bir kolaylık view'ı, altta yatan tablonun tamamını sessizce açığa çıkarabilir. Postgres 15 ve sonrasında — yazıya göre Supabase'in çalıştırdığı sürüm — çözüm tek bir ayar: security_invoker = on.

4. Gevşek grant'lar. RLS satırlara karar verir; grant'lar ise bir rolün o nesneye hiç dokunup dokunamayacağını belirler. anon veya authenticated rollerine verilmiş geniş bir grant, geniş bir policy'yi daha da kötüleştirir; yazı özellikle e-posta, key veya finansal kayıt içeren tablolardaki anon SELECT ayrıcalıklarını uyarıyor.

5. Herkese açık storage bucket'ları. Tablo seviyesindeki RLS, kendi erişim modeline sahip olan Supabase Storage için hiçbir şey yapmaz. Public olarak işaretlenmiş bir bucket, URL'yi bilen herkese herhangi bir nesneyi sunar; önerilen doğrulama yöntemi, bir dosyayı anon key ile istemek ve isteğin başarılı olup olmadığına bakmaktır.

6. Realtime abonelikleri. Realtime'ın postgres_changes özelliği, RLS'yi yalnızca yapılandırma doğruysa ve tablo supabase_realtime publication'ındaysa uygular. Yanlış yapılandırıldığında istemci, asla görmemesi gereken satırlara ait değişiklik olaylarını alabilir.

7. SECURITY DEFINER function'lar. Bunlar sahibi olarak çalışır — bu çoğunlukla RLS'nin kısıtlamadığı bir roldür — ve is_admin() gibi tetikleyici yardımcılarında yaygındır. anon tarafından çalıştırılabilirlerse, saldırgan function'ı doğrudan çağırıp sahip seviyesinde erişim kazanabilir. Yazıdan sağlamlaştırma önerileri: search_path = '' ayarlamak, function içinde auth.uid() doğrulaması yapmak ve gerçekten gerekmiyorsa anon'tan çalıştırma iznini geri almaktır.

Denetim yöntemi

Yazı, yedi vakayı da aynı şekli paylaşan olarak çerçeveliyor: RLS etkinleştirilmişti, dolayısıyla işin tamamlandığı varsayılmıştı. Yazar, Supabase SQL editöründe çalıştırılabilecek, pg_policies, information_schema.views, role_table_grants, pg_publication_tables ve pg_proc üzerinde salt okunur catalog sorgularından oluşan bir ilk tur öneriyor; ayrıca yaklaşık altmış kontrolü kapsayan açıklamalı denetim dosyalarından oluşan daha büyük bir set ve tenant izolasyonunu doğrulamak için iki kullanıcılı bir izolasyon harness'i de bulunduruyor.

Neden önemli

Supabase'ın anon key'i tasarımı gereği herkese açıktır ve her istemci paketine gömülü olarak gelir; dolayısıyla güvenlik sınırı tamamen sunucu tarafındaki yapılandırmada yaşar. "RLS etkin" ile "gerçekten özel" arasındaki boşluk, cross-tenant sızıntıların tam olarak bulunduğu yerdir ve yazının tarif ettiği başarısızlık modu — tek hesapla test ve ardından lansman — hızla derlenen, yapay zekâ destekli uygulamalarda yaygındır. Pratik test, bir bayrağın ayarlı olup olmadığı değil; her düşük ayrıcalıklı rolün, erişebildiği her nesneden gerçekte ne alabildiğidir.