Reeve Чи безпечний ваш застосунок на Supabase?
Supabase — це база даних і бекенд за величезною часткою vibe-coded застосунків. Вона потужна й безпечна, коли налаштована правильно — але кілька параметрів вирішують, приватні ваші дані чи відкриті всьому світу, і їх легко проґавити.
Reeve перевіряє ті, що мають значення, ззовні, безкоштовно, і пояснює знайдене простою мовою. Без встановлення, без доступу до вашого проєкту — ми дивимося лише на те, що вже досяжне, і ніколи не читаємо ваших справжніх даних.
Вставте посилання на застосунок. Близько 20 секунд. Оцінку видно без реєстрації.
Що насправді може піти не так із Supabase
Жоден із цих пунктів не означає, що ви зробили щось не так — це звичайні прогалини, коли рухаєшся швидко. Ось що варто перевірити:
Вимкнений Row Level Security (RLS)
RLS — це правило Supabase про те, хто може читати чи змінювати кожен рядок таблиці. З публічним «anon» ключем — який і має бути у вашому застосунку — будь-хто може напряму робити запити до вашої бази даних. RLS — це те, що не дає їм бачити рядки, які не їхні. Якщо його вимкнено, таблиця може бути повністю доступна для читання, або й редагування, будь-ким. Це найважливіший параметр Supabase, і Reeve перевіряє його, рахуючи рядки, а не читаючи їх.
Витік service_role ключа
Supabase дає вам два ключі. «anon» ключ публічний за задумом і безпечний у браузері. «service_role» ключ обходить усі ваші правила безпеки й має жити лише на сервері. Якщо він колись опиниться у фронтенд-коді вашого застосунку, будь-хто зможе робити з вашими даними будь-що. Reeve декодує знайдені ключі й точно каже, який із них відкритий — безпечний «anon» отримує зелену позначку, «service_role» — червону тривогу.
Публічні бакети сховища
Файли, які завантажують люди, живуть у «бакетах» Supabase Storage. Бакет, налаштований як публічний, означає, що будь-хто може переглянути список і завантажити те, що всередині — тож приватні завантаження можуть стати видимими всім. Reeve перевіряє, чи можна переглянути список ваших бакетів; він ніколи не завантажує чужих файлів.
Ваш API відкритий будь-якому сайту (CORS)
Supabase дає вашій базі даних вебадресу (через PostgREST). У поєднанні із занадто дозвільним налаштуванням обміну інший сайт міг би звертатися до ваших даних із браузера відвідувача. Reeve перевіряє, чи відповідають ваші ендпоінти стороннім та іншим сайтам — жодного разу не використовуючи їх, щоб щось змінити.
Таблиці й ендпоінти, відкриті без правил
Кожна створена вами таблиця досяжна через API Supabase — це за задумом, і RLS має її охороняти. Але нова таблиця, додана поспіхом, до того як задано її правила, може бути ненадовго (чи надовго) відкритою. Reeve перевіряє, що насправді досяжне ззовні.
Ключі чи конфігурація, лишені в задеплоєному застосунку
Окрім власних ключів Supabase, застосунки часто несуть інші налаштування й секрети у своєму фронтенд-коді або у відкритому .env. Reeve читає завантажений код застосунку й перевіряє досяжні файли конфігурації, а потім каже, які значення безпечно робити публічними, а які ні.
Що таке Reeve — і чим він не є
Reeve — це безкоштовна перевірка ззовні в режимі читання, наче інспектор, який перевіряє двері, не заходячи всередину. Це швидко, і це ловить поширені помилки з великими наслідками. Це не повний аудит безпеки, і чиста оцінка — не гарантія: вона означає, що очевидні двері зачинені. Усе, що робить Reeve, — пасивне: він рахує рядки, а не читає їх, і ніколи не завантажує ваших файлів.
Supabase дає вам справжні інструменти безпеки — Security Advisor і лінтер бази даних, що позначають проблеми з RLS і відкритістю прямо в панелі керування — і ними справді варто користуватися. Що додає Reeve: більшість тих, хто будує на Supabase, живуть у своєму конструкторі застосунків, а не в SQL-редакторі, і радник говорить мовою розробників. Reeve перевіряє весь ваш застосунок ззовні — так, як зловмисник дістався б до ваших даних — і пояснює знайдене простими словами. А якщо ви не хочете стежити за цим самі — це можемо ми.
Хочете, щоб цим займалися, а не лише перевірили?
Reeve Care продовжує стежити за вашим застосунком, робить резервні копії даних і допомагає полагодити, коли щось ламається — щоб ви могли будувати далі, а не хвилюватися.
Дізнатися про Reeve CareЧесні відповіді на запитання
Що таке Supabase RLS і чи справді він мені потрібен?
RLS (Row Level Security) вирішує, хто може бачити чи змінювати кожен рядок ваших таблиць. Оскільки ваш застосунок несе публічний «anon» ключ, яким можна напряму робити запити до бази даних, саме RLS не дає даним одного користувача стати видимими всім. Так — для будь-якої таблиці зі справжніми даними його треба ввімкнути. Reeve перевіряє, чи ввімкнено, не читаючи ваших даних.
Чи безпечно розкривати anon ключ Supabase?
Так — «anon» ключ створено, щоб жити у вашому фронтенді, і сам по собі він робить лише те, що дозволяють ваші правила RLS. Ключ, який ніколи не можна розкривати, — це «service_role», який ігнорує всі правила. Reeve декодує ключі у вашому застосунку й каже, який із них який.
Що станеться, якщо витече мій service_role ключ?
service_role ключ обходить кожне правило безпеки, тож будь-хто, хто його має, може читати, змінювати чи видаляти всі ваші дані. Якщо він у вашому фронтенд-коді, вважайте його скомпрометованим: замініть його в панелі керування Supabase й перенесіть на сервер. Reeve позначає відкритий service_role ключ як критичну проблему.
Чи може Reeve перевірити мій Supabase без пароля до бази даних?
Так. Reeve використовує лише те, що ваш застосунок уже публічно розкриває — той самий anon ключ і ендпоінти, якими користується браузер будь-якого відвідувача. Йому ніколи не потрібен пароль до вашої бази даних, він ніколи не входить як адміністратор і ніколи не читає й не завантажує ваших рядків чи файлів.
Будували застосунок у конкретному інструменті? Ось такий самий чесний розбір для:
Автоматична зовнішня перевірка, а не повний аудит. Відсутність знахідок не є гарантією безпеки.