Supabase RLS tarayıcısı: eksik veya bozuk row-level security olan tabloları bulun

Harici bir RLS taraması neyi kanıtlayabilir

Pasif bir RLS taraması, Supabase'in https://[project].supabase.co/rest/v1/ üzerinden sunduğu PostgREST endpoint'ine karşı çalışır. Yalnızca yayınlanabilir anon anahtarını kullanır — yani tarayıcınızın kullandığı anahtarın aynısını — ve tablo listesi meta verileri, anonim okumalar ve anonim yazmalar için sondalar gönderir. Asla bir kullanıcı olarak kimlik doğrulamaz ve asla service-role ayrıcalıklarına dokunmaz. Yapabildiği her şeyi, internetteki kimliği doğrulanmamış bir saldırgan da yapabilir.

Veritabanı dışından bir tarayıcı şunları yüksek güvenle teyit edebilir:

• Bir tabloda RLS devre dışı. RLS kapalıyken veya bir policy izin verirken PostgREST anonim bir SELECT için satır döndürür. Her iki durum da bulgudur.
• Anonim rol tabloları listeleyebilir. Anon anahtarıyla bir GET /rest/v1/ isteği, anon rolünün herhangi bir ayrıcalığa sahip olduğu her tablo için OpenAPI şemasını döndürür. Yapay zeka tarafından üretilmiş uygulamalar şema üzerinde USAGE ve her tabloda SELECT sıklıkla verir; bu, RLS gerçek okumayı reddetse bile tam şema haritasını ifşa eder.
• Anonim rol INSERT yapabilir. Sütun şekli tahmini içeren sondaj amaçlı bir POST, RLS'in onu reddeden bir INSERT policy'si yoksa başarılı olur — SELECT kilitli olsa bile.
• Service-role anahtarı tarayıcı paketinde. RLS'e komşu: tarayıcı JavaScript paketinde SUPABASE_SERVICE_ROLE_KEY veya role: service_role içeren herhangi bir JWT bulursa, RLS işlevsizdir — bu anahtarın sahibi her policy'yi atlar.

Harici bir tarama neyi kanıtlayamaz

Tarayıcının sınırları konusunda dürüst olun. Harici bir RLS taraması pg_policies tablonuzu, migration dosyalarınızı veya herhangi bir policy'nin tam yüklemini okuyamaz. Kara kutu davranışından çıkarımda bulunur, bu da bazen kasıtlı olarak açık olan veriler (bir pazarlama bülteni tablosu, açık bir ürün kataloğu) hakkında bir bulgu raporlayacağı anlamına gelir. FixVibe raporu, tarayıcının niyeti ayırt edemediği durumlarda bunları orta güven olarak işaretler — tablo adını inceleyin ve kararı verin.

Yapay zeka araçlarının ürettiği dört bozuk RLS biçimi

Cursor, Claude Code, Lovable veya Bolt'u Supabase'e yönlendirdiğinizde, binlerce uygulamada aynı dört bozuk RLS deseni ortaya çıkar. Her biri tip kontrolünden geçer, derlenir ve dağıtılır:

Biçim 1: RLS hiç etkinleştirilmemiş

En yaygın başarısızlık modu. Migration tabloyu oluşturur ama geliştirici (veya yapay zeka aracı) ALTER TABLE ... ENABLE ROW LEVEL SECURITY'i unutur. PostgREST anon anahtarına sahip herkese tablonun tamamını seve seve sunar. Düzeltme: ALTER TABLE public.[name] ENABLE ROW LEVEL SECURITY; ALTER TABLE public.[name] FORCE ROW LEVEL SECURITY;. FORCE isteğe bağlı değildir — onsuz tablo sahibi (ve tablo sahipliği olan herhangi bir rol) RLS'i atlar.

ALTER TABLE public.[name] ENABLE ROW LEVEL SECURITY;
ALTER TABLE public.[name] FORCE  ROW LEVEL SECURITY;

Biçim 2: RLS etkin, policy yok

Daha ince bir başarısızlık. RLS etkin ama hiçbir policy yazılmamış. PostgreSQL'deki varsayılan reddet'tir, bu yüzden kimliği doğrulanmış kullanıcılar hiçbir şey görmez — geliştirici de uygulamanın çalışması için USING (true) ekler ki bu herkesin her şeyi okumasına izin verir. Düzeltme: auth.uid()'ye göre kapsam belirleyen bir policy yazın: CREATE POLICY "select_own" ON public.[name] FOR SELECT USING (auth.uid() = user_id); ve eşleşen bir INSERT/UPDATE/DELETE policy'si.

CREATE POLICY "select_own"
  ON public.[name]
  FOR SELECT
  USING (auth.uid() = user_id);

Biçim 3: Policy sütunu kendisiyle karşılaştırıyor

A copy-paste artefact. The developer writes <code>USING (user_id = user_id)</code> — which is always true — instead of <code>USING (auth.uid() = user_id)</code>. Type-checks pass; the policy permits every row. <strong>Fix:</strong> always compare a column to a function call (<code>auth.uid()</code>, <code>auth.jwt()->>'org_id'</code>, etc.), never to itself or to a constant.

Biçim 4: SELECT'te policy var ama INSERT/UPDATE'te yok

Geliştirici okumaları kilitler ama yazmaları unutur. RLS policy'leri komut başınadır. FOR SELECT yalnızca okumaları korur; hiçbir policy reddetmiyorsa anonim bir istemci hâlâ INSERT yapabilir. Düzeltme: komut başına bir policy yazın veya açık USING ve WITH CHECK ifadeleriyle FOR ALL kullanın.

FixVibe Supabase RLS tarayıcısı nasıl çalışır

baas.supabase-rls kontrolü, her biri açık güven seviyeleriyle, üç aşamada çalışır:

1. Aşama 1 — parmak izi. Tarayıcı dağıtılmış uygulamayı tarar, JavaScript paketini ayrıştırır ve çalışma zamanı yapılandırmasından Supabase proje URL'sini ve anon anahtarını çıkarır. DNS tahmini yok, kaba kuvvet yok — tarayıcının okuduğunu okur.
2. Aşama 2 — şema keşfi. Anon anahtarıyla tek bir GET /rest/v1/ isteği, anon rolünün görebildiği her tablo için OpenAPI şemasını döndürür. Tarayıcı tablo adlarını kaydeder ancak bu aşamada satır verilerini okumaz.
3. Aşama 3 — okuma ve yazma sondaları. Keşfedilen her tablo için tarayıcı limit=1 ile bir anonim SELECT gönderir. Satırlar dönerse RLS müsamahakardır. Tarayıcı orada durur — satırları sıralamaz, sayfalama yapmaz, veriyi değiştirmez. INSERT sondaları doğrulanmış domain sahipliği ve açık opt-in arkasında kapılıdır; doğrulanmamış hedeflere karşı asla çalışmaz.

Her bulgu tam istek URL'si, yanıt durumu, yanıt şekli (yalnızca başlık) ve tablo adı ile birlikte gelir. Bulgunun altındaki yapay zeka düzeltme istemi, Supabase SQL editöründe çalıştırabileceğiniz kopyala-yapıştır bir SQL bloğudur.

Tarayıcı bir şey bulduğunda ne yapmalı

Her RLS bulgusu bir çalışma zamanı acil durumudur. Açık PostgREST endpoint'leri saldırganlar tarafından dakikalar içinde taranır. Düzeltme sırası mekanikseldir:

1. Her tabloyu denetleyin. Supabase SQL editöründe SELECT schemaname, tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public'; çalıştırın. rowsecurity = false olan her satır bir sorundur.
2. Her public tabloda RLS'i etkinleştirin. Oluşturulan her tabloda ENABLE ROW LEVEL SECURITY ve FORCE ROW LEVEL SECURITY'yi varsayılan yapın — bunu bir migration şablonu haline getirin.
3. Policy'leri komut komut yazın. FOR ALL USING (true) kullanmayın. SELECT, INSERT, UPDATE, DELETE için her biri auth.uid() veya auth.jwt()'den bir org-id sütununa kapsamlanmış açık policy'ler yazın.
4. İkinci bir hesapla doğrulayın. Farklı bir kullanıcı olarak kayıt olun, başka bir kullanıcının kayıtlarını doğrudan REST API üzerinden okumayı deneyin. Yanıt 200 ise policy bozuktur.
5. Yeniden tarayın. Düzeltmeyi uyguladıktan sonra aynı URL'ye karşı bir FixVibe taraması yeniden çalıştırın. baas.supabase-rls bulgusu temizlenmiş olmalı.

-- Audit every table for missing RLS. Run in the Supabase SQL editor.
SELECT schemaname, tablename, rowsecurity
FROM   pg_tables
WHERE  schemaname = 'public'
ORDER  BY rowsecurity, tablename;

Bu diğer tarayıcılara nasıl kıyaslanır

Çoğu genel DAST aracı (Burp Suite, OWASP ZAP, Nessus) PostgREST'in ne olduğunu bilmez. Uygulamanızı tarar, /rest/v1/ yolunu görmezden gelir ve anladıkları HTML sayfaları hakkında rapor verir. Snyk ve Semgrep statik analiz araçlarıdır — repo'nuzda eksik RLS çağrıları olan migration dosyalarını bulur, ancak dağıtılmış veritabanının yanlış yapılandırılmış olduğunu kanıtlayamazlar. FixVibe bu boşlukta yer alır: pasif, BaaS farkındalıklı, kimliği doğrulanmamış bir saldırganın açık URL'den ne kanıtlayabileceğine odaklı.

Sık sorulan sorular

Sonraki adımlar

Üretim URL'nize karşı ücretsiz bir FixVibe taraması çalıştırın — baas.supabase-rls kontrolü ücretsiz katman dahil her planda etkindir. Bir Supabase projesinden başka neler sızabileceğine dair daha derin bir okuma için JavaScript'te ifşa olan Supabase service role anahtarı ve Supabase storage bucket güvenlik kontrol listesi bölümlerine bakın. Tüm BaaS sağlayıcıları üzerindeki şemsiye görünüm için BaaS yanlış yapılandırma tarayıcısı bölümünü okuyun.