Які API-ключі безпечні у браузері, а які ні

Якщо ви зібрали застосунок у Lovable, Bolt, v0, Cursor чи Replit, рано чи пізно станеться таке: хтось відкриє ваш сайт, натисне F12 і повідомить, що ваш API-ключ «у відкритому доступі». Для застосунку, код якого ви й самі не читаєте, це тривожна новина.

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

Чи погано, що мій API-ключ видно?

Зазвичай ні. Усе залежить від того, який це ключ.

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

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

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

Чому ваш застосунок узагалі надсилає ключі у браузер

Бо запит іде з браузера вашого відвідувача, а не з вашого сервера.

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

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

Безпека береться не з приховування адреси. Вона береться з правил, які ви задаєте на іншому кінці: у випадку Supabase це Row Level Security, яка вирішує рядок за рядком, кому що видно. Саме ці правила варто перевіряти, а увімкнути їх не означає бути захищеним.

Дві родини ключів

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

Як розрізнити їх за 60 секунд

У Stripe і в більшості постачальників достатньо префікса. pk_ означає публічний і безпечний. sk_ означає секретний, а отже ні. Деякі постачальники ставлять посередині _test_ або _live_: витік тестового ключа створює значно меншу проблему, ніж витік бойового, але замініть обидва.

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

Нові проєкти: читайте префікс, так само як у Stripe. sb_publishable_… має жити у вашому застосунку. sb_secret_… – це той, який варто замінити сьогодні. Розкодовувати нічого не треба: для чого ключ, написано спереду. Що змінилося і що це означає для вашого застосунку, якщо ви ще з ними не стикалися.

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

В обох випадках інструмент не потрібен. Відкрийте Settings → API Keys в панелі Supabase, і там написано, який ключ який. Якщо ж вам зручніше перевірити той ключ, який ви справді знайшли у застосунку, середня частина старого ключа розкодовується приблизно в таке.

{
  "iss": "supabase",
  "ref": "abcdefghij…",
  "role": "anon",          ← ось це слово і має значення
  "iat": 1750000000
}

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

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

Що насправді стається, коли витікає секретний ключ

Кожен рядок вашої бази стає доступним для читання й запису тому, хто знайшов ключ, включно з таблицями, які ви ніколи не відкривали застосунку, і з персональними даними ваших користувачів. Row Level Security не поширюється на секретний ключ Supabase (sb_secret_…, або service_role у старішому проєкті). У цьому й полягає його призначення.

Шкода теж не теоретична. Зазвичай про неї дізнаються з повідомлення в підтримку про дані, які змінилися самі, або з таблиці, яка раптом виявилася порожньою.

Витік ключа sk_live_ у Stripe означає повернення, списання й картки клієнтів. Витік ключа постачальника ШІ означає рахунок, інколи дуже великий, який приходить раніше, ніж хтось це помітить.

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

Якщо потрібна версія для конкретної платформи, у нас є зрозумілий розбір для застосунків на Supabase.

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

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

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