<b>Supabase ломают не на SQL, а на правах доступа и границах API</b>

<b>Supabase ломают не на SQL, а на правах доступа и границах API</b>

Supabase часто ставят как «быстрый backend», а потом забывают, что у него есть три слоя риска: Postgres, auth и edge/API. Если приложение начало вести себя странно, почти всегда проблема не в базе как таковой, а в том, как вы связали таблицы, политики и публичные ключи.

Проверьте базовый набор:
— таблицы, доступные через client-side, защищены RLS;
— для каждой таблицы есть понятные политики на select/insert/update/delete;
— сервисный ключ не живёт в фронтенде и не утекает в логи;
— отдельные операции идут через server-only слой, а не напрямую из браузера.

Главная ошибка — дать фронту «почти всё» ради скорости. В Supabase это особенно опасно: один неверный policy, и пользователю открываются чужие записи, либо наоборот ломается тихая часть сценария, которую сложно отловить. RLS лучше писать не «на глаз», а как набор явных правил для ролей и сценариев.

Ещё одна зона боли — auth и storage. Если загрузка файла зависит от пользователя, проверьте не только bucket, но и путь, владельца, формат ссылки и время жизни доступа. Иначе у вас будет рабочая демка, которая разваливается на реальных правах.

<blockquote>Хорошая схема в Supabase — это когда фронт умеет только то, что разрешено политиками, а всё чувствительное уходит в серверные функции.</blockquote>

Перед запуском нового флоу прогоняйте его как чужой пользователь. Это быстрее всего вскрывает дыры.