<b>5 вещей в Supabase, которые ломают прод в первый же месяц</b>

<b>5 вещей в Supabase, которые ломают прод в первый же месяц</b>

Чаще всего проблемы не в самом Supabase, а в том, как его подключают к приложению. Если сразу не разложить auth, rls и схему данных, потом лечат уже инциденты, а не архитектуру.

— Таблицы доступны напрямую без RLS: один забытый policy превращает базу в публичный API.
— Service role утекает в клиент: после этого любое ограничение обходится.
— Смешивают пользовательские и системные роли: потом невозможно понять, кто и что может читать.
— Хранят бизнес-логику только в edge-функциях: перенос становится болезненным.
— Не тестируют запросы под разными ролями: в dev всё работает, в prod всплывают дыры.

Хорошая схема начинается с простого правила: клиент видит только то, что разрешено policy, а всё чувствительное живёт за server-side слоем. Для этого полезно держать отдельные роли, явно описывать доступ к таблицам и проверять, что каждый запрос проходит через нужный контекст rls.

Если у вас есть один час на аудит, начните с двух вещей: проверьте все policies и найдите места, где service key может попасть в браузер. Это быстрее, чем потом разбирать утечку и чинить доверие к системе.