Як замінити злитий ключ service_role у Supabase

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

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

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

Одне варто прояснити наперед. Видалити ключ із коду означає зняти власну копію зі зв'язки. Замінити його означає змінити замок. Лише друге дістає до копій, які вже є в інших.

Це справді ключ service_role?

У новішому проєкті відповідь дають перші кілька символів. sb_secret_ на початку означає секретний. sb_publishable_ це ключ, який і має бути у вашому застосунку, і знайти його там взагалі не знахідка.

Переконайтеся до того, як робити щось різке, бо ключ, який знаходять у застосунку, зібраному в стилі vibe coding, зазвичай і є тим, якому там місце.

Старіші проєкти видають іншу пару, anon і service_role, і ці два виглядають майже однаково: той самий формат, та сама довжина, жодного префікса для читання. Середня секція такого ключа взагалі не зашифрована. Вона розкодовується в кілька рядків звичайного тексту, і один із них називає роль. Які ключі API безпечні у фронтенді проходить обидві перевірки.

Причина переконатися в тому, що це трапляється рідше, ніж підказують попередження. У серпні 2026 року ми просканували 30 998 живих застосунків, зібраних у стилі vibe coding, і знайшли опублікований ключ service_role у 3 з них. Ключ API Google, який зазвичай нешкідливий і часто обмежений одним доменом, трапився в 1 142. Повний підрахунок тут.

Спершу замінити чи спершу закрити витік?

Це залежить від того, чи ключ уже публічний, і межа між двома випадками чітка.

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

Якщо він потрапив лише в приватний репозиторій, файл логу, змінну CI чи чат, розголос обмежений. Замінивши тут першою чергою, ви зробите це двічі, бо наступний деплой знову виштовхне старе значення з того, що його породжує, і новий ключ піде слідом за старим. Спершу закрийте джерело, потім замінюйте.

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

Як замінити секретний ключ Supabase

Якщо у вашому проєкті є ключі sb_secret_, це робота в панелі й без простою.

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

1. Відкрийте проєкт, перейдіть у Settings → API Keys і створіть новий секретний ключ.
2. Пропишіть його скрізь, де використовувався старий, а це все має бути на сервері: edge-функції, вебхуки, заплановані завдання, власний бекенд. Де лежать ці значення, якщо ви ніколи не відкривали ту сторінку.
3. Зробіть деплой, потім пройдіться частинами застосунку, які читають і пишуть дані. Неправильний секретний ключ падає гучно й одразу, і це добрий випадок.
4. Тільки після цього видаліть скомпрометований ключ.

Крок 4 остаточний. Supabase справді видаляє секретний ключ: без скасування, без повторного ввімкнення, без відкладеної копії, яку можна повернути. Тому він і йде останнім.

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

Чому старий ключ service_role у Supabase не можна замінити

Бо для цього немає кнопки. Нотатка Supabase з усунення несправностей каже, що пряма ротація старих секретів anon, service_role і JWT більше не підтримується, і скеровує вас до нових ключів.

Тож знецінити злитий старий ключ service_role це міграція, а не ротація:

1. Створіть нові ключі. Це додає sb_publishable_ і sb_secret_ поруч зі старою парою. Обидві системи працюють одночасно, і ніщо не ламається.
2. Переведіть фронтенд на публічний ключ. У Lovable чи Bolt це зазвичай одне значення в налаштуваннях проєкту, а не рядок коду.
3. Переведіть кожне серверне використання на секретний ключ.
4. Вимкніть старі ключі в налаштуваннях проєкту.

Крок 4 це один перемикач, і він стосується обох старих ключів. anon і service_role є JWT, підписаними тим самим секретом, тож перемикач, що відкликає один, відкликає й другий, а фронтенд, який досі несе старий ключ anon, перестає працювати тієї миті, коли ви його натискаєте. Саме тому крок 2 йде раніше.

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

Звідки витік ключ і як це закрити

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

Префікс VITE_ або NEXT_PUBLIC_. Це не налаштування безпеки, яке хтось забув увімкнути. Це вказівка збірці: поклади це значення в бандл. Змінна з назвою VITE_SUPABASE_SERVICE_ROLE_KEY потрапила у ваш JavaScript навмисно, через інструмент, який зробив рівно те, що йому сказали.

Значення, вставлене просто в компонент. Жодного префікса й жодного файлу .env, лише ключ у рядку коду, бо це був найшвидший спосіб змусити запит щось повернути.

Робота, місце якої на сервері. Видалити обліковий запис, записати в таблицю, куди вашим користувачам писати не можна, прочитати рядки по всіх одразу. За ключ узялися, бо браузер не міг виконати цю роботу, і рішення в тому, щоб перенести саму роботу: edge-функція, serverless-маршрут, будь-що, чого ваші відвідувачі не завантажують.

Як дізнатися, чи хтось ним скористався?

Зазвичай напевно дізнатися не вийде. Що ви можете, так це звузити вікно й зазирнути всередину.

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

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

Ключ service_role не дістає ні до вашого платіжного провайдера, ні до розсилання пошти. Усе одно варто знати, чи був він єдиним ключем у вашому бандлі, бо ті, що витрачають гроші, витікають тим самим шляхом: що публікували 30 998 застосунків.

Перевірте живий застосунок, перш ніж вважати справу закритою

Завантажте сайт у приватному вікні, відкрийте JavaScript, який завантажив браузер, і пошукайте в ньому старе значення. Потім пошукайте нове, якого там теж бути не повинно.

Дві речі роблять цю ручну перевірку доречною. Збірка може ще якийсь час після деплою віддавати закешований бандл, тож файл, який отримує відвідувач, не завжди той, що ви щойно зібрали. І ключ може лежати не в одному місці: друга точка входу, service worker, стара збірка, яку досі віддають зі шляху, на який ніхто не посилається.

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

Що робити зараз

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