Eksik Supabase Row Level Security, paketlenmiş anon key'leri açık veritabanlarına dönüştürüyor

Anon key'ler tasarım gereği herkese açık

Supabase destekli bir mobil uygulamanın güvenildiği yayınlanabilir anon key, kimsenin gizli tutamayacağı bir kimlik bilgisi değildir. dev.to'daki bir yazıya göre key, istemci paketinin içinde yer alıyor — örneğin bir Expo derlemesinde — ve herkes onu çıkarıp doğrudan veritabanını çağırmaya başlayabilir. Bir web uygulaması ayrıcalıklı key'leri sunucuda gizleyebilir; mobil uygulamanın böyle bir saklanma yeri yoktur.

Row Level Security (RLS), bu düzenlemeyi güvenli kılan mekanizmadır. Postgres içinde çalışır ve hangi istemci ya da betik gönderdiğinden bağımsız olarak her sorguya uygulanır. Doğru yapılandırıldığında, oturum açmış kullanıcılar yalnızca kendi satırlarını görür ve anonim çağrılar yalnızca gerçekten herkese açık verileri görür. Eksik olduğunda, yazı uyarıyor, bir uygulama geliştirmede tüm testleri geçebilirken üretimde tabloları her çağırana açık kalabilir — sızınyı bildiren bir hata olmadan.

İki kapı: grant'ler ve policy'ler

Supabase, anon key ile yapılan istekleri ya anon rolüne ya da authenticated rolüne eşler. Erişim kontrolü ardından iki katman üzerinden çalışır. Grant'ler, bir rolün bir tabloda select, insert, update veya delete çalıştırıp çalıştıramayacağına karar veren kaba izinlerdir. Policy'ler ise görünmez bir WHERE cümleciği gibi davranan satır düzeyinde kurallardır ve genellikle bir sahip sütununu JWT içinde gömülü kullanıcı kimliğiyle karşılaştırır.

Yazı, her iki katmanın da doğru olması gerektiğini vurguluyor. Eşleşen bir grant olmadan bir policy kapalı şekilde başarısız olur ve bir izin hatası üretir. Bir policy olmadan grant açık şekilde başarısız olur ve satırları döndürür. Yazar, yapay zekâ ile üretilmiş şemaların ikinci hata moduna eğilimli olduğunu savunuyor: hızla oluşturulmuş tablolar, hiç açılmamış RLS, geniş bırakılmış varsayılan grant'ler. Önerilen alışkanlık tekdüzedir —暴露 edilen bir şemadaki her tablo için RLS etkinleştirilir, en az grant verilir ve uygulamanın gerçekten gerçekleştirdiği her işlem için en az bir policy bulunur; arama tabloları ya da erken prototipler için istisna yapılmaz.

Varsayılan olarak sahip temelli erişim

Kullanıcı verisi için yazı basit bir sahip kalıbı öneriyor. Her tabloya, istekte bulunan kullanıcıya varsayılanlanan bir user_id sütunu verin; böylece sahipliği istemci değil, veritabanı JWT'den kaydeder. Policy'ler daha sonra bu sütunu auth.uid() ile karşılaştırır; using cümleciği okuma, güncelleme ve silme işlemlerini filtreler, with check cümleciği yazmaları doğrular. Kuralı simetrik tutmak, bir kullanıcının asla geri okuyamayacağı satırlar eklemesini ya da kimliğini tahmin ederek başkasının satırını değiştirmesini engeller.

Test, yapılandırma kadar önemlidir. Yazar, olumsuz yolu açıkça denetlemeyi öneriyor: bir kullanıcı olarak oturum açın, ardından başka bir kullanıcının satırını kimliğiyle okumaya, güncellemeye ve silmeye çalışın — üçü de reddedilmeli ya da hiçbir şey döndürmemelidir. Yalnızca sahiplerin kendi verilerine erişebildiğini doğrulayan bir test paketi, policy'nin yalızca yarısını kapsamıştır.

Herkese açık okumaları özel yazmalardan ayırın

Yalnızca sahibinin düzenleyebildiği herkese açık profiller gibi karma erişimli tablolar, tek bir serbest kural yerine işlem başına ayrı dar policy'ler almalıdır. Bir select policy'si anon rolünü açıkça adlandırmalı ve yalnızca gerçekten herkese açık veriler için olmalıdır. Başka her yerde, yazı anon'un grant'lerinin tamamen geri alınmasını, bir grant'in yokluğunu bir ihmalkârlık değil bilinçli bir kısıtlama olarak ele alınmesini öneriyor. RLS'yi atlamak için tasarlanmış service_role key yalnızca sunucu tarafı koda aittir; mobil akışlardan tetiklenen ayrıcalıklı işlemler, bir istemci policy'sini genişletmek yerine edge function'lar üzerinden yönlendirilmelidir.

Workspace'ler, performans ve atlatma yolları

Takım projeleri gibi paylaşılan kaynaklar, policy'lerin üzerinden birleştiği ve oturum açmış kullanıcının satırın workspace'ine ait olup olmadığını denetlediği bir üyelik tablosu gerektirir. RLS bir sorgunun dokunduğu her satırda çalıştığı için, yazı indekslenmemiş bir üyelik denetiminin yavaş bir uygulamaya dönüştüğü konusunda uyarıyor ve workspace_id ile user_id üzerinde indeks öneriyor. Ayrıca sık görülen bir kör noktaya dikkat çekiyor: yükseltilmiş ayrıcalıklarla çalışan view ve function'lar, temel tabloları koruyan policy'leri atlatABLE. Her biri ya çağıran olarak çalışmalı ya da kendi başına eşit derecede katı kurallar taşımalıdır; yazar, kullanıcı verisine dokunan her view ve function'ı listeleyen kısa bir denetim öneriyor.

Neden önemli

Yapay zekâ destekli geliştirme, satırlar akmaya başladığı anda backend'leri bitmiş gibi gösterir ve Supabase'in tasarımı istemci key'inin herkes tarafından bilindiğini varsayar. Bu, RLS'yi bir uygulamanın verileri ile key'i bir paketten çıkaran herkes arasındaki tek gerçek sınır haline getirir — ve hata modu sessizdir; çökme ya da hata yoktur, yalnızca yabancılara yanıt veren serbest tablolar vardır. Yayınlanabilir bir key ile gönderilen her mobil uygulama için, dev.to yazısındaki kontrol listesi — her tabloda RLS, en az grant, işlem başına policy, olumsuz yol testleri ve view ile function denetimi — çalışan bir uygulama ile açık bir uygulama arasındaki farktır.