Supabase Politikalarınızı Gerçekten Test Etmenin Kolay Yolu

Veri güvenliği, modern uygulamaların en kritik bileşenlerinden biridir. Ancak bu güvenliği sağlayan Row-Level Security (RLS) politikaları ne yazık ki çoğu zaman test edilmeden kalıyor. Üstelik, yanlış yapılandırılmış bir RLS politikası sistemde herhangi bir hata mesajı üretmiyor — sadece yanlış verileri döndürüyor. Bu da sorunun ancak kullanıcı şikayeti veya güvenlik ihlaliyle fark edilmesine yol açıyor.

RLS Politikaları Neden Test Edilmiyor?

Supabase belgeleri, RLS politikalarının test edilmesi için gereken pgTAP testlerinin "çoğu web geliştiricisi için erişilemez" olduğunu kabul ediyor. El ile bir politikayı test etmek için şunları yapmanız gerekiyor:

• - Farklı roller için kullanıcılar oluşturmak (sahip, diğer kullanıcı, anonim, rol sahibi)
• - Her kullanıcıya ait satırları veritabanına eklemek
• - Her kimliğe bürünmek (JWT iddialarını ve rolünü ayarlamak)
• - SELECT, INSERT, UPDATE ve DELETE işlemlerini her kimlik için çalıştırmak
• - Hangi satırlara erişebildiğinizi ve neleri değiştirebildiğinizi doğrulamak

Tüm bunlar, her tablo ve her politika için tekrarlanıyor. Üstelik, test verileri de kritik önem taşıyor. Boş bir tabloya karşı "sahip kendi satırını görüyor" testi yapmak, aslında hiçbir şey kanıtlamıyor. Bu karmaşıklık nedeniyle çoğu ekip, RLS güvenlik sınırlarını test etmekten vazgeçiyor ve uygulamalarını risk altında bırakıyor.

Gerçek Bir RLS Testi Neler Kontrol Etmeli?

Etkili bir RLS testi, her kimlik için aşağıdaki senaryoları doğrulamalıdır:

• - Sahip: Kendi satırlarını görmeli ve değiştirebilmeli
• - Diğer kullanıcı/kiracı: Hiçbir şekilde bu satırı görememeli
• - Anonim kullanıcı: Erişim engellenmeli
• - Rol sahibi: Politikaların izin verdiği ölçüde erişim sağlamalı

Testler, gerçekten ilgili kimliğe ait bir satır üzerinden yapılmalıdır. Ayrıca, izinlerin reddedilmesi iki şekilde olabilir:

• - Satır düzeyinde filtreleme: Doğru satırlar hiç gelmemeli
• - İzin hatası: Erişim tamamen engellenmeli

Bu detaylı doğrulama süreci, her politika için ayrı ayrı uygulanmalıdır.

Politikalarınızı Otomatik Olarak Test Edin

RLS politikalarınızı manuel olarak test etmek yerine, rlsautotest gibi araçlarla otomatikleştirmek çok daha verimli. Bu açık kaynaklı araç, PostgreSQL tabanlı veritabanlarınızın (Supabase, Neon, RDS vb.) RLS politikalarını otomatik olarak test ediyor ve size ayrıntılı raporlar sunuyor.

Kurulum ve Temel Kullanım

Aracı yüklemek için basit bir komut yeterli:

pip install rlsautotest

Daha sonra, testleri çalıştırmak için veritabanı bağlantı URL'sini belirtmeniz gerekiyor:

# HTML raporu olarak çıktısını almak için
rlsautotest --db-url "$DATABASE_URL" --schema public --html rls-raporu.html

# CI ortamına entegre etmek için pgTAP testleri olarak çıktısını almak için
rlsautotest --db-url "$DATABASE_URL" --schema public --emit supabase/

Rapor Nasıl Okunur?

Oluşturulan rapor, bir izin tablosu gibi görünür ve hangi rollerin hangi işlemleri gerçekleştirebileceğini gösterir:

          SELECT    INSERT    UPDATE    DELETE
---------------------------------------------
service_role       ✓         ✓         ✓         ✓
authenticated, authorized    ✓         ✓         ✓         ✓
authenticated, not authorized      ·         ·         ·         ·
anon               ·         ·         ·         ·

Burada dikkat edilmesi gereken, yanlış yerde bulunan ✓ işaretleri. Örneğin, anonim bir kullanıcının DELETE işlemini gerçekleştirebildiği bir durum varsa, bu açıkça görülür ve derhal düzeltilmesi gerekir.

RLS Politikalarında Gözden Kaçan Kritik Hata Türü

RLS politikalarıyla ilgili en tehlikeli hatalardan biri, iki farklı UPDATE politikasının kasıtsız şekilde birleşmesidir. Örneğin, bir tabloda iki farklı rol için ayrı ayrı izin veren UPDATE politikaları bulunabilir. Her politika, hangi değere güncelleme yapılabileceğini sınırlasa da, kimlerin güncelleme yapabileceği sadece USING koşulunda tanımlanırsa, bu politikalar birbirinin izinlerini genişletebilir.

PostgreSQL, izin veren her politikanın WITH CHECK koşullarını OR mantığıyla birleştirir. Bu da, aslında hiçbir politikada yetkisi olmayan bir rolün, diğer bir politikanın izin verdiği bir değeri güncelleyebilmesine yol açar. Her politika tek başına doğru görünebilir, ancak birlikte çalıştıklarında ciddi güvenlik açıkları oluşabilir. rlsautotest, her kimlik için hangi değerleri değiştirebileceğini ayrıntılı şekilde göstererek bu tür gizli açıkları ortaya çıkarır.

Araç Ne Yapmaz?

Bu araç, politikaların ne amaçladığını değil, neyi uyguladığını doğrular. Yani, yanlış yapılandırılmış ancak tutarlı bir politika yeşil olarak işaretlenebilir. Ayrıca, politikası olmayan komutlar varsayılan olarak engellenir ve ancak siz özellikle belirtirseniz test edilir. Politikalar karmaşık fonksiyonlara dayanıyorsa, araç bu durumu rapor eder ve varsayımlarda bulunmaz.

Araç, kanıtlayamadığı durumlarda emin olmadığını açıkça belirtir. Bu sayede, kullanıcıları yanıltıcı sonuçlardan korur. Yanlış güven oluşturan bir test aracından daha tehlikeli bir şey yoktur.

Sonuç: Politikalarınızı Bir Kez Test Edin

Eğer RLS politikalarınızdan emin değilseniz, rlsautotest aracını kullanarak bir kez test edin. Boş bir veritabanı kopyasına bağlanarak politikalarınızı otomatik olarak test edebilir ve olası sorunları erkenden tespit edebilirsiniz. Bu basit adım, veri sızıntılarını ve güvenlik açıklarını önlemenin en etkili yollarından biri olabilir.

Daha fazla bilgi ve kaynak kod için projenin deposuna göz atabilirsiniz. Veri güvenliği, uygulamanızın başarısı için kritik önem taşıyor — bu aracı kullanarak RLS politikalarınızın sağlam olduğundan emin olun.