# API-ключ, який доводиться випускати в браузер

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

Source: https://www.afterpack.dev/uk/docs/use-cases/shipped-api-keys

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

## Читабельний ключ знаходять боти, а не люди

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

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

## Що дає кодування ключа і де це закінчується

[`strings.encode`](https://www.afterpack.dev/uk/docs/config#strings-encode) увімкнений за будь-якої додатної цільової [`complexity`](https://www.afterpack.dev/uk/docs/config#complexity), тож рядкові літерали з вашого вихідного коду кодуються в результаті, а не випускаються текстом. Сканер, що шукає в бандлі через grep рядки, схожі на облікові дані, у такий спосіб ключа не знайде.

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

## Обмежте, сховайте за проксі, ротуйте, потім обфускуйте

Зробіть ці чотири кроки по черзі, і обфускація має бути останнім із них:

1. Обмежте ключ у провайдера найвужчою областю дії, джерелами (origins) і квотою, які той пропонує.
2. Перенесіть повноваження за власний ендпоінт, щоб браузер ніколи не тримав справжніх облікових даних.
3. Ротуйте ключ, який уже випущено. Вважайте його скомпрометованим із моменту, коли він вийшов назовні.
4. Обфускуйте те, що справді не можна перенести на сервер.

Для цього останнього кроку стандартна збірка вже кодує ключ. Щоб задати перевірку збірки для CI:

```json
{
  "strings": {
    "leaks": {
      "max": 0
    }
  }
}
```

[Директива](https://www.afterpack.dev/uk/docs/directives) піднімає захист одного значення вище за решту програми у збірках [Pro](https://www.afterpack.dev/uk/docs/tiers).

```ts
const apiKey = /* @afterpack preset=extreme */ "YOUR_SECRET";
```

## Зупиняйте збірку на вцілілому літералі

[`--strings.leaks.max=0`](https://www.afterpack.dev/uk/docs/config#strings-leaks-max) завершує збірку помилкою в ту мить, коли вціліє читабельний літерал, і називає [`DIAG_SURVIVING_READABLE_LITERAL`](https://www.afterpack.dev/uk/docs/diagnostics). Підключіть це до CI, щоб це не була перевірка на око. Щоб побачити, що розгорнутий сайт розкриває просто зараз, запустіть на ньому [`npx afterpack@latest audit`](https://www.afterpack.dev/uk/docs/audit).

## Випущений ключ однаково лишається випущеним

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

## Далі

- [FAQ](https://www.afterpack.dev/uk/docs/faq#how-do-i-protect-api-keys-and-license-logic): коротка відповідь саме на це запитання.
- [Модель загроз](https://www.afterpack.dev/uk/docs/threat-model#the-boundary): межа між статичним читачем і тим, хто запускає ваш код.
- [Найкращі практики](https://www.afterpack.dev/uk/docs/best-practices#if-you-shipped-a-secret-by-accident): кроки ротації, якщо ключ уже вийшов назовні.
