Lovable ile gurulan Supabase uygulamalarında sekiz veri sızıntı deseni ve bunları yakalayan SQL kontrolleri

dev.to'da yayımlanan bir yazı, Lovable ve Bolt gibi yapay zeka araçlarıyla Supabase üzerine kurulan uygulamaların kullanıcı verilerini açıkta bırakma biçimlerini katalogluyor ve her deseni, Supabase SQL editöründen birkaç dakikada çalıştırılabilecek kısa bir SQL kontrolüyle eşleştiriyor. Hata türleri, kabaca ne kadar kötü sonuç doğurduklarına göre sıralanmış.

Belgelenmiş bir sorun, varsayımsal değil

Yazar, yazıyı CVE-2025-48757'ye dayandırıyor ve Mart 2025'teki Matt Palmer haberciliğine atıfta bulunuyor: 170'ten fazla Lovable ile üretilmiş uygulama ve 303 açık uç noktası, e-postaları, telefon numaralarını, ödeme ve abonelik verilerini ile üçüncü taraf API anahtarlarını açığa çıkardı; bazı durumlarda yazma erişimi de vardı, yani ödeme kayıtları yalnızca okunmakla kalmayıp değiştirilebiliyordu. Lovable'ın yanıtı, 2.0 sürümüyle gelen yerleşik bir güvenlik tarayıcısıydı. Yazıya göre bu tarayıcı yalnızca RLS'nin açık olup olmadığını doğruluyor — politikaların gerçekten kimseyi kısıtlayıp kısıtlamadığına dair hiçbir şey söylemiyor — ve anlatılan desenlerin tümü RLS'yi açık tutuyor ve taramadan geçiyor.

Yazar bunun araçların kendisine bir takma olmadığını açıkça belirtiyor. RLS, bir prompt'un tam olarak tanımlayamayacağı tek Supabase uygulaması parçasıdır: her şirketin yalnızca kendi projelerini gördüğü bir uygulama talebi, üreticiye tenant sınırını güvenilir biçimde bulmanın bir yolunu vermez; dolayısıyla bu politikaların bilinçli olarak, tablo tablo yazılması gerekir.

Kullanıcının yazabildiği roller ve RLS'siz tablolar

Yazarın en kötü diye nitelediği ve tam da üretici için en kolay yol olduğu için sık gördüğü desen, rol veya organizasyon üyeliğini user_metadata içinde saklamak. Bu nesne kullanıcı tarafından yazılabilir, bu yüzden oturum açmış herkes tarayıcı konsolunu açıp auth.updateUser çağırarak role alanını admin yapabilir ve iddia ettiği her şeye dönüşebilir. O alan'a güvenen politikalar, kullanıcının kendisi hakkındaki iddiasından fazlasını zorunlu kılmaz. Önerilen çözüm, auth.uid() ile anahtarlanmış, istemciden kullanıcıların yazamadığı politikaya sahip ayrı bir üyelik tablosu ya da istemcilerin değiştiremediği app_metadata'dır.

İkinci hata daha kaba. Public şemasındaki her tablo Supabase'in REST API'si üzerinden erişilebilirdir ve RLS'nin etkin olmadığı yerde anon anahtarı — herkesin okuyabileceği frontend bundle'ının içinde gömülü gelen — tablonun tamamını döndürür. Yazı, Supabase kontrol panelinin bu konuda uyardığını, ancak uyarının sürüme giden yolda tıklanıp geçilmesinin kolay olduğunu belirtiyor.

Var olan ama evet diyen politikalar

Bunlar bir tarayıcının göremeyeceği hatalar, çünkü yapısal olarak gerçek politikalardır. Kaba versiyon genellikle bir geliştirici izin hatasıyla karşılaştığında ve bir yapay zekadan bunu düzeltmesini istediğinde ortaya çıkar: bir select üzerindeki using (true) hatayı kaybettirir ve oturum açmış her kullanıcının her satırı okumasına izin verir. Yazı ayrıca anonim oturum açma etkinleştirildiğinde — Auth ayarlarındaki tek bir anahtar — authenticated'ın artık anlamlı bir sınır olmaktan çıktığını ekliyor.

İnce versiyon daha sinsice: EXISTS alt sorgusu yalnızca geçerli kullanıcının bir organizasyona üye olduğunu doğrulayan, bu üyeliği hiçbir zaman filtrelenen satırla ilişkilendirmeyen bir politika. Postgres her satır için aynı soruyu sorar, evet cevabını alır ve veriyi teslim eder. Herkes kayıt olup ücretsiz bir workspace oluşturabilir ve düz bir select ile her müşterinin siparişlerini okuyabilir; bir istismar zinciri gerekmez. Çözüm tek bir join ile üyeliğin tenant_id'sini tablonunkiyle eşleştirmek, ayrıca planlayıcının fonksiyonu satır başına bir kez yerine sorgu başına bir kez değerlendirmesi için bir (select auth.uid()) sarmalayıcısı eklemektir — büyük tablolarda bu, hayatta kalan bir politika ile yavaş olduğu için silinen bir politika arasındaki farktır.

Service anahtarları, eksik kontroller ve view'lar

RLS'yi bir politika yazmadan açmak her şeyi reddeder ve en hızlı çözüm genellikle Supabase'i, RLS'yi tamamen atlayan service role anahtarıyla çağırmaktır. Bu anahtar tarayıcının erişebildiği herhangi bir yerdeyse, veritabanındaki tüm korumalar onu bulan kişi için kapalıdır. Yazar, gurulan bundle içinde service_role için grep yapmayı, bulunan her JWT'yi çözmeyi — payload base64'tür, şifreli değil — ve git geçmişini kontrol etmeyi öneriyor; çünkü ne kadar hızlı kaldırılmış olsa da bir kez commit edilmiş bir anahtarın rotasyonu yapılmalıdır; otomatik tarayıcılar herkese açık depoları gün boyu izler.

Listenin başka bir yerinde: WITH CHECK yan tümcesi olmayan INSERT ve UPDATE politikaları kullanıcıların org_id'yi yeniden yazmasına ve kayıtları başka bir müşterinin hesabına taşımasına ya da hesabından çıkarmasına izin verir; alışılmış şüpheliler FOR ALL politikalarıdır. Ayrıca view'lar sahibinin ayrıcalıklarıyla çalışır — Supabase'te genellikle postgres — dolayısıyla korumalı bir tablo üzerindeki view, altındaki politikalardan bağımsız olarak her şeyi döndürür. Postgres 15'te eklenen security_invoker seçeneği bunu ele alır ve varsayılan olarak kapalıdır.

Neden önemli

Yapay zeka uygulama geliştiricileri çalışan yazılımı ucuz üretilebilir hale getirdi, ancak tüm bu hataların paylaştığı özellik — bir müşterinin verisinin nerede bittiği ve diğerininkinin nerede başladığı — tam olarak bir üreticinin tahmin edemeyeceği ve yapısal bir tarayıcının doğrulayamayacağı şeydir. CVE-2025-48757, bu açığın ölçekte gerçek olduğunu, teorik olmadığını gösterdi. Yazının denetimleri pg_policies ve pg_class'a karşı sorgular artı gurulan bundle'ın bir grepidir ve pratik çıkarım basittir: bunları uygulama piyasaya çıkmadan önce çalıştırın, başkası yapmadan sonra değil.