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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Як розрізнити їх за 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-хвилинний чекліст безпеки охоплює цей пункт і решту речей, які варто вимкнути у щойно запущеному застосунку.

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