Гачок
Захист проекту 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 потрібні чіткі політики для визначення користувачів або ролей, які можуть виконувати операції з сегментами файлів. [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]