Supabase Row Level Security увімкнено. Таблиця досі публічна.

Ви увімкнули Row Level Security, бо щось вам це підказало: advisor усередині Supabase, чекліст, результат сканування, хтось у Discord. Перемикач у вашій панелі тепер зелений. І вам усе одно кажуть, що вашу таблицю досі можуть читати сторонні.

Ось те, що посібник за посібником переказує неправильно: перемикач не захищає нічого. Він вирішує, що ваші правила почнуть перевіряти. Правила лишаються окремою річчю, писати їх маєте ви, а найшвидше правило з усіх (те, з яким зламаний застосунок знову працює) впускає всіх.

Row Level Security увімкнено в Supabase. Чому таблиця досі публічна?

Бо увімкнути й вирішити, кого пускати, означає два різні кроки, і лише перший з них перемикач.

Уявіть перемикач як людину, яку ви поставили біля дверей. Перевести його не означає вирішити, хто пройде. Це означає, що тепер хтось звіряє список. Ваші політики і є той список. Порожній список не пускає нікого; список зі словом «усі» не спиняє нікого. І те, і те лишається Row Level Security в увімкненому стані, і ваша панель показує однакову зелень в обох випадках.

Саме тому налаштування саме по собі відповідає на дуже мало, і саме тому наш сканер ніколи не питає Supabase, чи воно активне. Він питає таблицю. Він надсилає той самий запит, що надіслав би сторонній, з публічним ключем, який їде всередині вашого застосунку, і дивиться, чи повернеться відповідь. Він просить кількість, а не самі рядки, тож дізнається, що двері відчинилися, не читаючи нічого за ними.

Політика, яка полагодила застосунок, найімовірніше і є проблемою

Тієї миті, коли ви вмикаєте Row Level Security, ваш застосунок перестає показувати дані, і те, що ви зробили далі, аби він знову запрацював, і є тим, на що варто подивитися.

Ця послідовність цілком звичайна, і саме тут усе йде не так. З увімкненим налаштуванням і без жодної написаної політики Postgres (рушій бази даних, на якому працює Supabase) за замовчуванням відхиляє кожен запит, тож ваші списки повертаються порожніми, а екрани лишаються білими. Щось має потрапити до списку. Якщо ви попросили Cursor чи Lovable це полагодити або вставили перший уривок, після якого помилка зникла, те, що ви маєте зараз, найпевніше має такий вигляд:

CREATE POLICY "Enable read access for all users"
  ON public.profiles
  FOR SELECT
  USING (true);

USING (true) задає умову, яку рядок має задовольнити, перш ніж база даних його віддасть. Умову true задовольняє кожен рядок. Там усередині є друга деталь, повз яку легко пройти: без клаузи TO політика діє для public, а public однаково охоплює й відвідувачів, які увійшли, і цілком сторонніх людей.

Отже, застосунок знову працює, ніде немає помилки, а таблиця читається рівно так само, як і до того, як ви почали.

Це лагодить читання, і тільки читання. Якщо ваш застосунок ще й зберігає в цю таблицю, наступне, що ви зустрінете, це new row violates row-level security policy, тобто те саме налаштування, яке відмовляє в записі, і жодна політика читання цього не прибере.

Чотири стани, в яких може бути таблиця

Два з них безпечні, а два ні, і перемикач не каже вам, які саме. «Публічний ключ» нижче означає той, якому місце у вашому застосунку: sb_publishable_… у нових проєктах Supabase, anon у старіших.

Два середні стовпці і є саме тією парою, на якій люди спотикаються. Те саме налаштування, той самий зелений значок, протилежні наслідки, а різниця вміщається в одне слово всередині правила, яке майже ніхто ніколи не відкриває.

Якщо вам не хочеться читати кожну політику самотужки, наше безкоштовне сканування ставить вашій живій базі те саме запитання, що й сторонній, і каже, які таблиці відповіли. Це триває близько 20 секунд і не потребує акаунта: просканувати застосунок.

«Authenticated» не означає те саме, що «ваш»

Політика, яка дозволяє authenticated, дозволяє всім, хто має акаунт, а це (якщо у вашому застосунку відкрита реєстрація) усі, хто готовий її заповнити.

Це тонший варіант тієї самої помилки, і він переживає чимало переглядів, бо має охайний вигляд. TO authenticated USING (true) читається як обмеження, і воно ним є: воно відсікає тих, хто ніколи не реєструвався. Чого воно не робить, так це не спиняє одного вашого клієнта від читання рядків іншого клієнта, а саме це ви зазвичай і мали на увазі під словом «приватне».

Правило, яке це робить, називає власника рядка:

CREATE POLICY "Users read their own rows"
  ON public.orders
  FOR SELECT
  TO authenticated
  USING (auth.uid() = user_id);

auth.uid() означає того, хто питає. user_id означає стовпець у рядку, який каже, кому цей рядок належить. Рядок повертається, коли ці двоє збігаються, і лишається на місці, коли ні.

Як перевірити власні таблиці за дві хвилини

Відкрийте Supabase, зайдіть в Authentication → Policies і читайте вираз усередині кожної політики, а не значок біля кожної таблиці.

Три речі, які варто шукати:

• Політику, умова якої true. Вирішуйте таблиця за таблицею, чи спокійно вам було б бачити ці дані на відкритій сторінці. Для переліку опублікованих статей відповідь буде «так», для будь-чого, де є людина, – «ні».
• Політику без клаузи TO. Вона діє для всіх, хоч ви увійшли, хоч ні, навіть коли решта правила має дуже конкретний вигляд.
• Таблицю з увімкненим налаштуванням, без жодної політики, і застосунок, який попри це працює. Це поєднання означає, що до ваших даних дістається щось іншим шляхом, і звичним поясненням є секретний ключ: sb_secret_…, або service_role у старішому проєкті. Він ігнорує кожну написану вами політику. Які ключі API безпечні у фронтенді розповідає, як відрізнити його від безпечного.

Інша перевірка, до якої вдаються, полягає в тому, щоб відкрити застосунок у приватному вікні без входу. Її варто зробити, але знайте, що саме вона доводить. Ваш застосунок вирішує, що показати. Ваша база даних вирішує, що віддати. Це різні рішення, і сторонній, який оминає ваші екрани, отримує друге.

Який вигляд це має, поки триває

Ніякого. Саме такої форми ця річ, і саме тому вона лишається на місці місяцями.

У вашому білдері не з'являється жодної помилки. Ніщо не сповільнюється, жоден екран не ламається, жоден лист не приходить. Ваш застосунок поводиться точно так, як у день запуску, бо з його боку нічого не змінилося: він завжди мав право читати ці рядки. Змінилося те, що це право мають і всі інші, з ключем, який їде в коді, що ваш сайт надсилає кожному відвідувачу.

Коли це випливає, то випливає збоку. Клієнтка питає, звідки хтось знав те, що знав лише ваш застосунок. Список адрес, який ви ніколи не публікували, десь виринає. А якщо щедре правило охоплює і запис, FOR ALL замість FOR SELECT, то будь-хто може ще й змінювати та видаляти рядки. Цей варіант люди помічають як таблицю, що раптом стала порожньою.

Правила ще й зсуваються. Міграція, зміна схеми, чергова нічна лагодка, якій треба було, щоб дані завантажились: будь-що з цього здатне послабити політику, нічого про це не сказавши. Тому тут вартий уваги другий погляд згодом, а не лише один тепер. Стежити за цим є частиною того, що робить Reeve Care, хоча нагадування у вашому календарі виконує те саме завдання.

Що зробити цього тижня

Почніть з тієї таблиці, за яку вам було б найніяковіше, якби вона була відкритою сторінкою, і розберіться з нею сьогодні. 10-хвилинний чеклист безпеки охоплює це разом з рештою того, що варто переглянути у щойно запущеному застосунку, а посібник із безпеки Supabase проходить по тому, що ще зазвичай лишається відкритим.