Supabase'ın 30 Ekim değişikliği yeni tablolara API erişimini kesiyor; toplu GRANT çözümü verileri yeniden açık hale getirebilir

30 Ekim'de ne değişiyor

Mateus Zingano'nun dev.to'daki bir gönderisine göre Supabase, 30 Ekim 2026'da API'ye bakan rollerine tablo ayrıcalıkları vermeyi bırakacak. Daha önce public şemasında oluşturulan her tablo, anon, authenticated ve service_role rollerine otomatik olarak select, insert, update ve delete ayrıcalıklarını alıyordu. Değişiklik yürürlüğe girdiğinde, açık bir GRANT olmadan oluşturulan tablo Data API üzerinden hiç erişilemeyecek — supabase-js, PostgREST ve GraphQL'nin tamamı etkileniyor — ve tablonun nasıl oluşturulduğu fark etmiyor: SQL editörü, migration dosyası, CLI, MCP veya bir AI kodlama asistanı.

Gönderinin özetlediği değişikliğin sınırları:

• Mevcut tablolar sahip oldukları grant'leri koruyor, dolayısıyla çalışan uygulamalar etkilenmiyor.

• Row-level security ve politikalar olduğu gibi kalıyor. Grant'ler bir rolün tabloya hiç dokunup dokunamayacağını belirler; RLS ise hangi satırları görebileceğini belirler.

• Yeni projeler, 30 Mayıs'ta başlayan kademeli dağıtımdan beri zaten daha katı varsayılan üzerinde.

• Doğrudan Postgres bağlantısı üzerinden veritabanına konuşan her şey — psql, bir ORM, bağlantı dizesi kullanan bir backend — etkilenmiyor. Zingano bu noktayı Supabase'ın resmi duyurusuna dayandırıyor.

Bozulma nasıl görünüyor

Geçişten sonra oluşturulan ilk tablo, satırlar yerine eksik grant'e işaret eden bir ipucuyla birlikte Postgres 42501 permission-denied hatası döndürüyor. Postgres sorguyu RLS hiç değerlendirilmeden önce reddediyor; yani bu, uygulamanın politikalarındaki bir hata değil, tasarlandığı gibi çalışan yeni varsayılan.

Neden bariz çözüm riskli olan

Hatanın kaybolmasının en hızlı yolu, public içindeki her tabloya üç rolün tamamına dört işlemin tümünü veren tek bir toplu ifade — Zingano'nun Supabase'ın kendi duyurusunun geri alma bölümünden aktardığı bir satır. İşe yarıyor, ama aynı zamanda hiç açığa çıkarılmak istenmemiş tablolara da erişim veriyor. RLS kapalı olan herhangi biri, projenin anon anahtarını elinde tutan herkes tarafından okunabilir — ve muhtemelen yazılabilir — hale geliyor; bu anahtar frontend'in içinde gömülü geliyor. Yeni varsayılan tam da yanlışlıkla açığa çıkmayı durdurmak için vardı; toplu grant onu yeniden devreye sokuyor. Zingano ayrıca bir AI aracından "izin hatasını düzeltmesini" istemenin bu genelge ifadeyi muhtemel bir cevap haline getirdiğini belirtiyor.

Onun önerdiği alternatif daha yavaş ama güvenli: tablo tablo grant verin ve her role yalnızca gerçekten ihtiyaç duyduğu işlemleri verin.

Önerdiği migration deseni

Tablo tanımını, RLS etkinleştirmesini, politikaları ve grant'leri aynı migration içinde tek bir birim olarak ele alın; böylece tablo hiçbir zaman kısmen yapılandırılmış bir durumda var olmaz. Örnek uygulamasında bir invoices tablosu RLS etkinleştirmesi, authenticated kullanıcılarına kısıtlı yalnızca sahibinin okuyabileceği bir select politikası ve authenticated'a tek bir select grant'i alıyor. anon'a hiçbir şey verilmiyor, çünkü oturum açmamış ziyaretçilerin faturaları okumak için bir gerekçesi yok.

Bir dikkat noktası: tablo identity sütunu yerine serial veya bigserial kullanıyorsa ve API ona insert yapıyorsa, arka plandaki sequence'ın kendi usage grant'ine ihtiyacı var.

API'nin bugün neye erişebildiğini denetlemek

Gönderi, public içindeki her tablo ve view'i, anon ya da authenticated'ın okuyup okuyamadığını ve RLS'nin açık olup olmadığını listeleyen, has_any_column_privilege ile birleştirilmiş pg_class üzerinde bir sorgu sunuyor. Zingano, her zamanki information_schema.table_privileges yerine has_any_column_privilege'ı tercih ediyor, çünkü o ayrıca sütun düzeyindeki grant'leri de ortaya çıkarıyor: belirli sütunlara kısıtlanmış bir grant tablo ayrıcalığı olarak görünmez, ama API yine de o sütunları sunar. anon'un okuyabildiği ve RLS'nin kapalı olduğu her satır, anon anahtarına sahip herkesin okuyabileceği bir tabloyu işaret ediyor.

Zamanla işleri dürüst tutmak için iki ücretsiz, MIT lisanslı araç öneriliyor: airlock-migrate, migration dosyalarını CI'da okur ve biri RLS etkinleştirmeden tablo oluşturduğunda ya da RLS'yi kapattığında build'i başarısız kılar; airlock-rls ise canlı bir veritabanında RLS kapalı tabloları ve herkese izin veren politikaları kontrol eder. Yayına alınmış bir uygulamanın service_role anahtarını tarayıcıya sızdırıp sızdırmadığını ya da okunabilir tablo açığa çıkarıp çıkarmadığını test etmek için ücretsiz bir harici tarayıcıdan da bahsediliyor; yalnızca satır sayılarını rapor ediyor ve verinin kendisini asla okumuyor.

Neden önemli

Bu, aynı anda hem gerçek bir güvenlik iyileştirmesi hem de operasyonel bir tuzak olan platform değişikliklerinden biri. 30 Ekim'in kendisinde hiçbir şey bozulmuyor — acı, hata mesajının değişikliğin sağlamayı amaçladığı korumayı sessizce geri alan bir çözüme davet ettiği ilk yeni tabloyla geliyor. Supabase üzerinde yayın yapan ekipler geçişten önce mevcut grant'lerini ve RLS kapsamlarını denetlemeli, tablo bazlı grant'leri migration şablonlarına yerleştirmeli ve CI'ya otomatik bir kontrol koymalı; böylece yeni varsayılanın güvenlik payı aceleye getirilen migration'larla tek tek erimesin. Daha geniş ders Supabase'ın ötesine genelleniyor: grant'ler ve row-level security ayrı katmanlardır ve biri diğerinin yerine geçmez.