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

Harici bir RLS taraması neyi kanıtlayabilir

A passive RLS scan looks at your Supabase project the way an anonymous visitor would. It uses only the publishable anon key — the same key your browser uses — and never authenticates as a user or touches service-role privileges. Anything it can see, an unauthenticated attacker on the internet can see.

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.
• Read access does not establish write safety. A passive scan cannot prove that INSERT, UPDATE, or DELETE policies protect every user and tenant. Review write policies and test them with isolated fixtures under the intended roles.
• 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

When you point Cursor, Claude Code, Lovable, or Bolt at Supabase, the same four broken-RLS patterns come up again and again. Each one passes type-check, compiles, and ships:

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

The most common failure mode. The migration creates the table but the developer (or the AI tool) forgets ALTER TABLE ... ENABLE ROW LEVEL SECURITY. PostgREST happily serves the entire table to anyone with the anon key. Fix: ALTER TABLE public.[name] ENABLE ROW LEVEL SECURITY;, then add a policy per command. Enabling RLS with no policies denies all access through the API; the policies decide who gets in.

ALTER TABLE public.[name] ENABLE 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

Bir kopyala-yapıştır kalıntısı. Geliştirici, USING (auth.uid() = user_id) yerine USING (user_id = user_id) yazar — ki bu her zaman doğrudur. Tip kontrolleri geçer; policy her satıra izin verir. Düzeltme: her zaman bir sütunu bir fonksiyon çağrısıyla karşılaştırın (auth.uid(), auth.jwt()->>'org_id' vb.), asla kendisiyle veya bir sabitle değil.

Shape 4: Overly permissive write policies

With RLS enabled, a role with no applicable policy is denied by default. A SELECT policy does not itself allow INSERT. Write exposure can arise from a permissive applicable INSERT or ALL policy, disabled RLS, or a role that bypasses RLS. Fix: inspect table privileges and every applicable policy, use ownership-scoped WITH CHECK conditions, and test writes with separate user identities.

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

FixVibe's Supabase check works from the deployed app, in three steps:

1. Find the project. FixVibe loads the deployed app and reads the Supabase project URL and public key from the same configuration your browser receives. No guessing, no brute force.
2. See what is exposed. FixVibe checks which tables the anonymous role can see, without reading row data at this step.
3. Stage 3 — inspect anonymous read access. The passive check reports observable access to discovered resources. It does not create, update, or delete database rows, and it cannot establish that all write policies or cross-user boundaries are correct.

Each finding ships with the exact request URL, response status, response shape (header-only), and the table name. FixVibe now labels whether the fix belongs in code/config, a provider console, DNS, secret rotation, or manual review so the next step matches who can actually apply it.

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. Enable RLS on every public table. Default to ENABLE ROW LEVEL SECURITY on every table created — make it a migration template.
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. Re-scan. After applying the fix, re-run a FixVibe scan against the same URL. The Supabase RLS finding should clear.

-- 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

Run a free FixVibe scan against your production URL — the Supabase RLS check runs on every plan including the free tier. For a deeper read on what else can leak from a Supabase project, see Supabase service role key exposed in JavaScript and Supabase storage bucket security checklist. For the umbrella view across all BaaS providers, read BaaS misconfiguration scanner.