Supabase RLS skaneri: əskik və ya pozulmuş sətir səviyyəsində təhlükəsizliyi olan cədvəlləri tapın

Xarici RLS skanı nəyi sübut edə bilər

Passiv bir RLS skanı Supabase-in https://[project].supabase.co/rest/v1/ ünvanında təqdim etdiyi PostgREST endpoint-inə qarşı işləyir. Yalnız ictimai anon açarını istifadə edir — brauzerinizin istifadə etdiyi açarın eynisini — və cədvəl-siyahı metaməlumatı, anonim oxuma və anonim yazma üçün zondlamalar göndərir. Heç vaxt bir istifadəçi kimi identifikasiya olunmur və heç vaxt service-role imtiyazlarına toxunmur. Onun edə bildiyi hər şeyi, internetdə identifikasiyasız bir hücumçu da edə bilər.

Verilənlər bazasından kənarda bir skaner aşağıdakıları yüksək etibarla təsdiqləyə bilər:

• Bir cədvəldə RLS söndürülüb. RLS söndürüldükdə və ya bir policy icazə verdiyində PostgREST anonim SELECT üçün sətirlər qaytarır. Hər iki halda bu, bir tapıntıdır.
• Anonim rol cədvəlləri sadalaya bilər. Anon açarı ilə bir GET /rest/v1/ sorğusu, anon rolunun hər hansı imtiyazı olduğu hər cədvəl üçün OpenAPI sxemini qaytarır. AI tərəfindən yaradılmış tətbiqlər tez-tez sxemə USAGE və hər cədvələ SELECT verir; bu, RLS faktiki oxuma əməliyyatlarını rədd etsə belə tam sxem xəritəsini ifşa edir.
• Anonim rol INSERT edə bilər. Sütun formasını təxmin edən zondlayıcı bir POST, RLS-də onu rədd edən bir INSERT policy yoxdursa uğurlu olar — SELECT bağlı olsa belə.
• Service-role açarı brauzer bundle-ində. RLS-ə bitişik: əgər bir skaner JavaScript bundle-də SUPABASE_SERVICE_ROLE_KEY və ya role: service_role olan hər hansı JWT taparsa, RLS mənasızdır — həmin açarın sahibi hər policy-ni keçir.

Xarici skan nəyi sübut edə bilməz

Skanerin hüdudları barədə dürüst olun. Xarici RLS skanı sizin pg_policies cədvəlinizi, miqrasiya fayllarınızı və ya hər hansı policy-nin dəqiq predikatını oxuya bilməz. O, qara-qutu davranışından nəticə çıxarır, deməli bəzən qəsdən ictimai olan məlumatı (marketinq bülleten cədvəli, ictimai məhsul kataloqu) tapıntı kimi bildirə bilər. FixVibe hesabatı, skaner niyyəti dəqiqləşdirə bilmədikdə bunları orta etibarlılıq kimi qeyd edir — cədvəl adına baxın və qərar verin.

AI alətlərinin yaratdığı dörd pozulmuş RLS forması

Cursor, Claude Code, Lovable və ya Bolt-u Supabase-ə yönəltdikdə minlərlə tətbiqdə eyni dörd pozulmuş RLS nümunəsi ortaya çıxır. Hər biri tip yoxlamasından keçir, kompilyasiya olunur və deploy edilir:

Forma 1: RLS heç vaxt aktivləşdirilməyib

Ən çox rast gəlinən uğursuzluq tipi. Miqrasiya cədvəli yaradır, lakin tərtibatçı (və ya AI alət) ALTER TABLE ... ENABLE ROW LEVEL SECURITY əmrini unudur. PostgREST anon açarı olan hər kəsə bütün cədvəli xoş könüllə təqdim edir. Düzəliş: ALTER TABLE public.[name] ENABLE ROW LEVEL SECURITY; ALTER TABLE public.[name] FORCE ROW LEVEL SECURITY;. FORCE seçimli deyil — onsuz cədvəl sahibi (və cədvəl sahibliyi olan istənilən rol) RLS-i keçir.

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

Forma 2: RLS aktiv, policy yoxdur

Daha incə bir uğursuzluq. RLS aktivdir, lakin heç bir policy yazılmayıb. PostgreSQL-də standart rədddir, ona görə identifikasiya olunmuş istifadəçilər heç nə görmür — və tərtibatçı tətbiqi işlətmək üçün USING (true) əlavə edir, bu da hər kəsə hər şeyi oxumağa icazə verir. Düzəliş: auth.uid() üzərindən əhatəli policy yazın: CREATE POLICY "select_own" ON public.[name] FOR SELECT USING (auth.uid() = user_id); və uyğun INSERT/UPDATE/DELETE policy-si.

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

Forma 3: Policy sütunu özü ilə müqayisə edir

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.

Forma 4: SELECT-də policy var, INSERT/UPDATE-də yox

Tərtibatçı oxumaları bağlayır, lakin yazmaları unudur. RLS policy-ləri əmr başına işləyir. FOR SELECT yalnız oxumaları qoruyur; rədd edən policy yoxdursa anonim müştəri yenə də INSERT edə bilər. Düzəliş: hər əmr üçün bir policy yazın və ya açıq USING və WITH CHECK ilə FOR ALL istifadə edin.

FixVibe Supabase RLS skaneri necə işləyir

baas.supabase-rls yoxlaması, hər biri açıq etibarlılıq səviyyəsi ilə üç mərhələdə işləyir:

1. Mərhələ 1 — barmaq izi. Skaner deploy olunmuş tətbiqi crawl edir, onun JavaScript bundle-ini parse edir və işləyiş zamanı konfiqurasiyasından Supabase layihə URL-i və anon açarını çıxarır. DNS təxmini yox, brute force yox — brauzerin oxuduğunu oxuyur.
2. Mərhələ 2 — sxem aşkarlama. Anon açarı ilə tək bir GET /rest/v1/, anon rolunun görə biləcəyi hər cədvəl üçün OpenAPI sxemini qaytarır. Skaner cədvəl adlarını qeyd edir, lakin bu mərhələdə sətir məlumatlarını oxumur.
3. Mərhələ 3 — oxuma və yazma zondları. Aşkarlanan hər cədvəl üçün skaner limit=1 ilə bir anonim SELECT göndərir. Sətirlər qayıdırsa, RLS izin vericidir. Skaner orada dayanır — sətirləri sadalamır, səhifələmir, məlumatı dəyişmir. INSERT zondları təsdiqlənmiş domen sahibliyi və açıq icazə tələb edir; onlar heç vaxt təsdiqlənməmiş hədəflərə qarşı işləmir.

Hər tapıntı dəqiq sorğu URL-i, cavab statusu, cavab forması (yalnız başlıq) və cədvəl adı ilə birlikdə gəlir. Tapıntının altındakı AI düzəliş tövsiyəsi, Supabase SQL redaktorunda işə salacağınız kopyala-yapışdır SQL blokudur.

Skaner bir şey tapdıqda nə etməli

Hər RLS tapıntısı işləyiş zamanı təcili haldır. İctimai PostgREST endpoint-ləri dəqiqələr ərzində hücumçular tərəfindən skanlanır. Düzəliş ardıcıllığı mexanikidir:

1. Hər cədvəli audit edin. Supabase SQL redaktorunda SELECT schemaname, tablename, rowsecurity FROM pg_tables WHERE schemaname = 'public'; işlədin. rowsecurity = false olan hər sətir problemdir.
2. Hər ictimai cədvəldə RLS-i aktivləşdirin. Yaradılan hər cədvəldə ENABLE ROW LEVEL SECURITY və FORCE ROW LEVEL SECURITY standart olsun — bunu miqrasiya şablonu edin.
3. Policy-ləri əmr-əmr yazın. FOR ALL USING (true) istifadə etməyin. SELECT, INSERT, UPDATE, DELETE üçün açıq policy-lər yazın — hər biri auth.uid() və ya auth.jwt()-dən bir org-id sütununa əhatəli olsun.
4. İkinci hesabla doğrulayın. Fərqli istifadəçi kimi qeydiyyatdan keçin, REST API ilə birbaşa başqa istifadəçinin yazılarını oxumağa cəhd edin. Cavab 200-dürsə, policy pozulub.
5. Yenidən skanlayın. Düzəlişi tətbiq etdikdən sonra eyni URL-ə qarşı yenidən FixVibe skanı işlədin. baas.supabase-rls tapıntısı təmizlənməlidir.

-- 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 digər skanerlərlə necə müqayisə olunur

Əksər ümumi DAST alətləri (Burp Suite, OWASP ZAP, Nessus) PostgREST-in nə olduğunu bilmir. Tətbiqinizi crawl edəcək, /rest/v1/ yolunu görməzdən gələcək və başa düşdüyü HTML səhifələrini bildirəcəklər. Snyk və Semgrep statik analiz alətləridir — onlar reponuzda əskik RLS çağırışları olan miqrasiya fayllarını tapırlar, lakin deploy olunmuş bazanın səhv konfiqurasiya edildiyini sübut edə bilmirlər. FixVibe bu boşluqda yer alır: passiv, BaaS-fərqlandə, ictimai URL-dən identifikasiyasız bir hücumçunun sübut edə biləcəklərinə fokuslanmış.

Tez-tez verilən suallar

Sonrakı addımlar

Produksiya URL-inizə qarşı pulsuz bir FixVibe skanı işlədin — baas.supabase-rls yoxlaması pulsuz tarif daxil olmaqla hər planda aktivdir. Supabase layihəsindən başqa nələrin sıza biləcəyinə dair daha dərin oxuma üçün JavaScript-də ifşa olunmuş Supabase service role açarı və Supabase storage bucket təhlükəsizlik yoxlama siyahısı baxın. Bütün BaaS provayderləri üzrə ümumi baxış üçün BaaS səhv konfiqurasiya skaneri oxuyun.