Куката
Защитата на Supabase проект изисква многопластов подход, фокусиран върху API управление на ключове, сигурност на базата данни и разрешения за съхранение. [S1] Неправилно конфигурирана защита на ниво ред (RLS) или разкрити чувствителни ключове могат да доведат до значителни инциденти с излагане на данни. [S2] [S3]
Какво се промени
Това изследване консолидира основните контроли за сигурност за Supabase среди, базирани на официални насоки за архитектура. [S1] Фокусира се върху прехода от конфигурации за разработка по подразбиране към закалени в производството позиции, по-специално по отношение на механизмите за контрол на достъпа. [S2] [S3]
Кой е засегнат
Приложенията, използващи Supabase като Backend-as-a-Service (BaaS), са засегнати, особено тези, които обработват специфични за потребителя данни или лични активи. [S2] Разработчиците, които включват ключа service_role в пакети от страна на клиента или не успеят да активират RLS, са изложени на висок риск. [S1]
Как работи проблемът
Supabase използва защитата на ниво ред на PostgreSQL, за да ограничи достъпа до данни. [S2] По подразбиране, ако RLS не е активиран на таблица, всеки потребител с ключа anon, който често е публичен, може да има достъп до всички записи. [S1] По същия начин, Supabase Storage изисква изрични политики, за да дефинира кои потребители или роли могат да извършват операции с файлови пакети. [S3]
Какво получава нападателят
Хакер, притежаващ публичен ключ API, може да използва таблици, в които липсва RLS, за да прочете, модифицира или изтрие данни, принадлежащи на други потребители. [S1] [S2] Неоторизиран достъп до кофи за съхранение може да доведе до излагане на лични потребителски файлове или изтриване на критични активи на приложения. [S3]
Как FixVibe го тества
FixVibe вече покрива това като част от своите проверки Supabase. baas.supabase-security-checklist-backfill преглежда публичните Supabase метаданни на кофата за съхранение, излагането на списък на анонимни обекти, чувствителното именуване на кофата и необвързаните сигнали за съхранение от публичната анонимна граница. Свързаните проверки на живо инспектират излагането на ключ на ролята на услугата, положението на Supabase REST/RLS и SQL миграциите на хранилището за липсващ RLS.
Какво да поправя
Винаги активирайте защитата на ниво ред на таблиците на базата данни и прилагайте подробни политики за удостоверени потребители. [S2] Уверете се, че само ключът 'anon' се използва в кода от страна на клиента, докато ключът 'service_role' остава на сървъра. [S1] Конфигурирайте контрола на достъпа до хранилището, за да гарантирате, че файловите пакети са частни по подразбиране и достъпът се предоставя само чрез дефинирани политики за сигурност. [S3]