FixVibe

// docs / baas security / supabase storage

Supabase storage bucket təhlükəsizlik yoxlama siyahısı: 22 maddə

Supabase Storage, S3-uyğun bir bucket üzərində nazik bir wrapper və verilənlər bazası ilə eyni Row-Level Security modelini istifadə edir. Bu o deməkdir ki, cədvəllərə təsir edən eyni RLS tələləri fayl girişinə də təsir edir — və AI kodlaşdırma alətləri yükləmələri qurduqda ortaya çıxan bir neçə storage-spesifik tələ də var. Bu yoxlama siyahısı beş bölmədə 22 maddədir: bucket konfiqurasiyası, RLS policy-ləri, yükləmə yoxlaması, signed URL-lər və əməliyyat gigiyenası. Hər biri 15 dəqiqədən az müddətdə yoxlanıla bilər.

Aşağıdakı hər maddə vacibdir. Əsas RLS mexanikası üçün Supabase RLS skaneri-nə baxın. Storage-ə bitişik açar-ifşası sinifi üçün JavaScript-də ifşa olunmuş Supabase service role açarı-na baxın.

Bucket konfiqurasiyası

Düzgün standart dəyərlərlə başlayın. Səhv konfiqurasiya edilmiş bir bucket, RLS-iniz düzgün olsa da olmasa da, faylları sızdırır.

  1. Hər bucket-i standart olaraq şəxsi edin. Supabase Dashboard → Storage → Buckets-də açıq səbəb (marketinq materialları, PII-siz ictimai avatar-lar) olmadıqca Public bucket seçimini bağlı edin. İctimai bucket-lər oxuma əməliyyatları üçün RLS-i keçir — bucket adını bilən hər kəs onu sadalaya və yükləyə bilər.
  2. Hər bucket-də sərt fayl ölçüsü məhdudiyyəti təyin edin. Dashboard → Bucket settings → File size limit. İstifadəçi yükləmələri üçün 50 MB ağıllı bir standartdır; video / böyük-fayl istifadə hallarında qəsdən artırın. Limit olmadan, tək zərərli bir yükləmə storage kvotanızı və ya aylıq trafik limitinizi tükətə bilər.
  3. Hər bucket-də icazə verilən MIME tiplərini məhdudlaşdırın. İcazə verilən MIME tipləri siyahısı — blocklist yox, açıq allowlist. Yalnız şəkil bucket-ləri üçün image/jpeg, image/png, image/webp. İstifadəçi-məzmun bucket-ində heç vaxt text/html, application/javascript və ya image/svg+xml-ə icazə verməyin — onlar signed URL ilə təqdim edildikdə brauzerdə icra olunur.
  4. Bir məzmun tipi üçün bir bucket istifadə edin, ortaq bir bucket yox. Bucket-başına parametrlər (ölçü, MIME tipləri, RLS policy-ləri) sizdə olan dənəliklədir. Bir user-avatars bucket-i, bir document-uploads bucket-i və bir public-assets bucket-i qarışıq bir bucket-dən daha asan kilidlənir.
  5. Frontend yükləmələri varsa CORS konfiqurasiyasını yoxlayın. İstifadəçilər birbaşa brauzerdən signed URL-ə yükləyirsə, bucket CORS produksiya origin-inizi sadalamalıdır. * yalnız ictimai bucket-lər üçün qəbul edilə bilər — heç vaxt istifadəçi PII-si olan bucket-lər üçün yox.

storage.objects-də RLS policy-ləri

Supabase Storage fayl metaməlumatını storage.objects cədvəlində saxlayır. Bu cədvəldə RLS, kimin faylları oxuya, yükləyə, yeniləyə və ya silə biləcəyini idarə edir. RLS olmadan, bucket-in ictimai/şəxsi bayrağı sizin yeganə müdafiənizdir.

  1. storage.objects-də RLS-in aktiv olduğunu təsdiqləyin. SELECT rowsecurity FROM pg_tables WHERE schemaname = 'storage' AND tablename = 'objects'; true qaytarmalıdır. Supabase bunu yeni layihələrdə standart olaraq aktivləşdirir; deaktiv edilmədiyini yoxlayın.
  2. Şəxsi bucket-lər üçün auth.uid()-ə əhatəli bir SELECT policy yazın. CREATE POLICY "users_read_own_files" ON storage.objects FOR SELECT USING (auth.uid()::text = (storage.foldername(name))[1]);. Konvensiya faylları [user-id]/[filename] altında saxlamaq və yolundan sahibi çıxarmaq üçün storage.foldername() istifadə etməkdir.
  3. Eyni yol konvensiyasını icra edən bir INSERT policy yazın. CREATE POLICY "users_upload_own" ON storage.objects FOR INSERT WITH CHECK (auth.uid()::text = (storage.foldername(name))[1]);. WITH CHECK olmadan, identifikasiya olunmuş bir istifadəçi başqa istifadəçinin qovluğuna yükləyə bilər.
  4. Tətbiqiniz fayl redaktəsini və ya silməsini dəstəkləyirsə UPDATE və DELETE policy-ləri əlavə edin. Hər əmrin öz policy-si lazımdır. DELETE-i atlamaq identifikasiya olunmuş istifadəçilərin öz fayllarını silə bilməyəcəyi deməkdir; UPDATE-i atlamaq fayl üst-yazmalarının sakitcə uğursuz olması deməkdir.
  5. İki brauzer sessiyasında istifadəçilərarası girişi test edin. İstifadəçi A kimi daxil olun, bir fayl yükləyin, yolunu kopyalayın. Başqa bir brauzerdə İstifadəçi B kimi daxil olun, REST API ilə faylı götürməyə cəhd edin. Cavab 403 və ya 404 olmalıdır, heç vaxt 200 yox.
sql
-- Confirm RLS on storage.objects
SELECT rowsecurity
FROM   pg_tables
WHERE  schemaname = 'storage' AND tablename = 'objects';

-- SELECT policy: scope reads to the owning user's folder.
CREATE POLICY "users_read_own_files"
  ON storage.objects
  FOR SELECT
  USING (auth.uid()::text = (storage.foldername(name))[1]);

-- INSERT policy: enforce the [user-id]/[filename] path convention.
CREATE POLICY "users_upload_own"
  ON storage.objects
  FOR INSERT
  WITH CHECK (auth.uid()::text = (storage.foldername(name))[1]);

Yükləmə yoxlaması

Bucket-də MIME və ölçü məhdudiyyətləri olsa belə, hər yükləməni server tərəfdə yoxlayın. AI kodlaşdırma alətləri standart olaraq yalnız müştəri tərəfli yoxlama yaradır; bu heç nəyi qorumur.

  1. MIME tipini server tərəfində Content-Type başlığından deyil, faylın faktiki baytlarından yenidən yoxlayın. file-type (Node) kimi bir kitabxana və ya sehrli-bayt iyləməsini istifadə edin. Hücumçu əslində polyglot HTML / JavaScript payload olan bir faylda Content-Type: image/jpeg iddiasında ola bilər.
  2. Yüklənmiş şəkillərdən EXIF metaməlumatını çıxarın. EXIF GPS koordinatlarını, cihaz seriya nömrələrini və zaman möhürlərini ehtiva edə bilər. Saxlamadan əvvəl çıxarmaq üçün sharp.withMetadata(false) ilə və ya exif-parser-i istifadə edin.
  3. script teqləri və ya onload handler-ləri olan SVG-ləri rədd edin. SVG XML-dir — və bir çox AI tərəfindən yaradılmış tətbiq SVG yükləmələrinə "sadəcə şəkil" kimi icazə verir. Server tərəfdə DOMPurify istifadə edin və ya SVG yükləmələrini tamamilə rədd edin.
  4. Deterministik, təxmin olunmayan fayl adları istifadə edin. Orijinal fayl adını saxlamayın. UUID və ya fayl məzmununun hash-ini istifadə edin. Orijinal fayl adları sızdırır ("passport_scan_2024_01_15.jpg") və proqnozlaşdırıla bilən adlar sıralanmağa imkan verir.

Signed URL-lər

Signed URL-lər müştərilərin şəxsi bucket-lərə necə daxil olduğudur. Bitmə müddəti, bucket əhatə dairəsi və nələrin qeydə alındığı vacibdir.

  1. Signed URL bitmə müddətini standart olaraq 1 saat və ya daha az təyin edin. Supabase JS SDK-nin createSignedUrl(path, expiresIn)-i saniyə alır. 31536000 (bir il) kimi dəyərlərdən heç vaxt istifadə etməyin — URL daimi yarı-ictimai bağlantıya çevrilir.
  2. Signed URL-ləri verilənlər bazanızda heç vaxt saxlamayın. Hər sorğuda server tərəfdə təzələrini yaradın. 1 illik bitmə müddətli saxlanan bir signed URL bir verilənlər bazası dump-ı vasitəsilə sızdıqda uzunmüddətli giriş təmin edir.
  3. Yalnız fayl yükləmələrini yox, signed URL yaradılmasını da qeyd edin. Sonradan bir kompromis şübhəsi olduqda, kimin hansı URL-i nə vaxt yaratdığını bilməlisiniz. auth.uid() + bucket + obyekt yolu + zaman möhürünü qeyd edin.
  4. İstifadəçi yüklədiyi faylları təqdim edərkən downloadAs seçimini istifadə edin. createSignedUrl(path, expiresIn, { download: '.jpg' }) faylın render olunmaq əvəzinə yüklənməsi üçün Content-Disposition: attachment başlığını məcburi edir — HTML / SVG / PDF-də HTML icra sinifini neytrallaşdırır.

Əməliyyat gigiyenası

Storage konfiqurasiyası zamanla dəyişir. Bu dörd əməliyyat maddəsi səthi sıx saxlayır.

  1. Bucket-ləri rüblük audit edin. Dashboard → Storage → Buckets. İctimai/şəxsi vəziyyətinin və MIME-tipi siyahılarının tətbiqin gözlədiyi ilə uyğun olduğunu təsdiqləyin. "Müvəqqəti" yaradılan bucket-lər heç kim onları silməyəndə daimi olur.
  2. Anonim list əməliyyatlarını izləyin. Storage logları (Dashboard → Logs → Storage) LIST sorğularını qeyd edir. Şəxsi bucket-ə qarşı anonim list sorğularının artması, kiminsə onu xaricdən zondladığı deməkdir.
  3. Müvəqqəti yükləmələr üçün saxlama policy-si təyin edin. Müvəqqəti bucket-lər (şəkil ön baxışı, qaralama yükləmələr) cədvəlli funksiya ilə 24-72 saatdan sonra avtomatik silinməlidir. Müddətsiz saxlama GDPR / CCPA məlumat-minimizasiya öhdəlikləri çərçivəsində məsuliyyətdir.
  4. Ayda bir FixVibe skanı işlədin. baas.supabase-storage-public yoxlaması anonim GET + LIST-ə cavab verən bucket-ləri zondlayır. Yeni bucket-lər əlavə olunur; köhnələri görünürlük dəyişir — yalnız davamlı skanlama bu dəyişikliyi tutur.

Sonrakı addımlar

Produksiya URL-inizə qarşı FixVibe skanı işlədin — anonim storage listələri baas.supabase-storage-public altında görünür. Bu yoxlama siyahısını cədvəl qatı üçün Supabase RLS skaneri və açar-ifşa bitişikliyi üçün JavaScript-də ifşa olunmuş Supabase service role açarı ilə birləşdirin. Digər BaaS provayderləri üzrə storage səhv konfiqurasiyaları üçün BaaS səhv konfiqurasiya skaneri-nə baxın.

// baas səthinizi skanlayın

Açıq cədvəli başqası tapmazdan əvvəl tapın.

Bir produksiya URL-i daxil edin. FixVibe tətbiqinizin əlaqə qurduğu BaaS provayderlərini sadalayır, ictimai endpoint-lərinin barmaq izini götürür və identifikasiyasız müştərinin nə oxuyub yaza biləcəyini bildirir. Pulsuz, quraşdırma yox, kart yox.

  • Pulsuz tarif — ayda 3 skan, qeydiyyat üçün kart tələb olunmur.
  • Passiv BaaS barmaq izi — domen təsdiqi tələb olunmur.
  • Supabase, Firebase, Clerk, Auth0, Appwrite və daha çoxu.
  • Hər tapıntıda AI düzəliş tövsiyələri — Cursor / Claude Code-a yapışdırın.
Pulsuz BaaS skanı başlat

qeydiyyat tələb olunmur

Supabase storage bucket təhlükəsizlik yoxlama siyahısı: 22 maddə — Docs · FixVibe