> ## Documentation Index
> Fetch the complete documentation index at: https://www.helius.dev/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Защита вашего ключа

> Что может и чего не может делать ключ Helius API, доступный в вашем приложении со встроенным кошельком, и как защитить его с помощью контроля доступа, безопасных RPC URL и прокси.

SDK wallet-kit работает в браузере, поэтому ваш Helius `apiKey` присутствует на стороне клиента: при загрузке приложения провайдер отправляет его в точку **инициализации** кошелька (`/waas/config`). Это ожидаемое поведение для клиентского SDK. На этой странице подробно объясняется, что этот ключ может и чего не может делать, а также как его защитить.

## Что ключ может — и чего не может — делать

Начните с этого, поскольку здесь легко ошибиться: **ключ Helius API — это учетные данные для RPC/кредитов, а не ключ кошелька.**

Утекший ключ **не может**:

* подписывать транзакции или сообщения,
* перемещать средства или получать к ним доступ,
* взаимодействовать со встроенным кошельком любого пользователя.

Подписание транзакций в кошельке авторизуется с помощью **собственного ключа доступа или сеанса конечного пользователя**, а приватные ключи хранятся в защищенных анклавах [Turnkey](https://www.turnkey.com) — они никогда не находятся в вашем приложении, на вашем сервере или в любом месте, к которому может получить доступ ключ API. **Раскрытие ключа не раскрывает кошельки.**

Утекший ключ **может** расходовать ваши **кредиты Helius** (квоту RPC). Этим ограничивается весь потенциальный ущерб: речь идет о расходах, а не о хранении средств. Описанные ниже уровни защиты ограничивают и устраняют этот риск.

<Note>
  **Раскрытие ключа также не позволяет обойти оплату.** Подписи WaaS учитываются в
  момент подписания встроенным кошельком, а не на уровне ключа API — утекший ключ не
  позволяет бесплатно создавать подписи или начислять оплату за подписи с чужого сайта. Учет
  не зависит от секретности ключа.
</Note>

## Защитите ключ

Эти уровни перечислены от требующего меньше всего усилий до самого надежного ограничения. Первый уровень — обязательная основа; добавьте остальные в соответствии с допустимым для вас риском.

### 1. Ограничьте ключ по доменам (обязательно)

Ограничьте ключ источниками, на которых работает ваше приложение, чтобы ключ, извлеченный из сборки, был бесполезен в других местах.

<Steps>
  <Step title="Open RPC Access Control">
    На [панели управления](https://dashboard.helius.dev) откройте свой ключ в разделе
    **RPCs**, а затем откройте **Access Control**.
  </Step>

  <Step title="Add your domains to Allowed Domains">
    Добавьте каждый источник, с которого предоставляется ваше приложение: рабочую среду, промежуточную среду и среду предварительного просмотра:

    ```
    yourdapp.com
    www.yourdapp.com
    staging.yourdapp.com
    ```
  </Step>

  <Step title="Use a separate key per environment">
    Используйте отдельные ключи для локальной, промежуточной и рабочей сред, чтобы можно было заменить один ключ,
    не нарушая работу остальных.
  </Step>
</Steps>

<Note>
  **Списки разрешенных доменов предотвращают неправомерное использование в браузере, но не останавливают целенаправленный скрипт.**
  Проверка считывает заголовок `Origin`/`Referer` запроса — браузер задает его
  корректно, но небраузерный клиент (например, `curl -H "Origin: yourdapp.com"`) может
  его подделать. Это относится к **любому** клиентскому ключу API, а не только к Helius.
  Ограничение по доменам надежно предотвращает распространенный сценарий — использование вашего ключа
  на чужом сайте. Но если нужно ограничение, которое *невозможно* подделать, используйте
  серверный ключ, привязанный к вашим IP-адресам/CIDR ([шаг 4](#4-добавьте-неподделываемое-ограничение-по-ipcidr)).
</Note>

### 2. Безопасные RPC URL без ключа (автоматически)

RPC-трафик вообще не содержит вашего ключа. Во время инициализации SDK получает **безопасный RPC URL без ключа** вашего проекта и автоматически использует его для вызовов `connection` — ничего настраивать не нужно.

Поскольку эти URL **не содержат ключа**, из RPC-запроса нечего извлекать. Для них также действует **ограничение в 5 запросов в секунду на один IP-адрес**, поэтому их защита не зависит от проверки Origin. (Доступно на платных тарифах; если у проекта нет безопасного RPC URL, RPC переключается на обработчик маршрута того же источника, описанный на шаге 3.)

### 3. Перенесите ключ на серверную сторону — без собственного сервера

Чтобы ключ не попадал в браузер при вызовах RPC, отправке и получении истории транзакций, направляйте эти вызовы через собственную конечную точку, которая добавляет ключ из **серверного** секрета. Таким же образом можно подключить [оптимизированную через Sender отправку](/docs/ru/sending-transactions/sender) и историю транзакций.

Оба варианта **на 100% бессерверные** — вам не нужно обслуживать сервер:

* **Обработчик маршрута Next.js** — развертывается как бессерверная функция (Vercel, Netlify, Cloudflare). Считывает `HELIUS_API_KEY` из серверного окружения.

  ```ts app/api/helius/[...path]/route.ts theme={"system"}
  import { createHeliusRouteHandler } from "helius-wallet-kit/next";

  export const { GET, POST } = createHeliusRouteHandler();
  ```

* **Прокси Cloudflare Worker** — самый простой полностью бессерверный вариант: ключ хранится в секрете Worker и никогда не попадает в браузер.

  <Card title="Helius RPC Proxy" icon="github" href="https://github.com/helius-labs/helius-rpc-proxy">
    Прокси RPC с открытым исходным кодом, который можно развернуть в Cloudflare одним нажатием.
  </Card>

### 4. Добавьте неподделываемое ограничение по IP/CIDR

Чтобы создать ограничение, которое злоумышленник **не сможет подделать**, привяжите **серверный** ключ к IP-адресам или диапазонам CIDR вашего бэкенда. В отличие от заголовка `Origin`, **исходный IP-адрес невозможно подделать** при обычном подключении, поэтому `curl`, отправленный не с ваших серверов, будет сразу отклонен.

Это применимо только к **серверному** ключу: ограничить браузерный ключ по IP-адресам нельзя, поскольку пользователи подключаются с непредсказуемых IP-адресов. Рекомендуемая схема предполагает **два ключа**:

| Ключ | Кем используется | Ограничение |
| - | - | - |
| Публичный / браузерный ключ | провайдер `config` (инициализация) | Разрешенные **домены** |
| Серверный ключ | обработчик маршрута / Worker (RPC, отправка) | Разрешенные **IP-адреса/CIDR** |

<Note>
  Бессерверные функции используют **динамические исходящие IP-адреса**, поэтому для привязки CIDR требуется
  стабильный исходящий адрес — Cloudflare Worker с выделенным исходящим IP-адресом, Vercel Secure
  Compute или NAT с фиксированным IP-адресом. Даже без этого вы получаете главное преимущество:
  ключ находится на серверной стороне и никогда не попадает в браузер. Вы лишь не добавляете поверх этого
  ограничение по IP-адресам.
</Note>

Полное описание правил контроля доступа приведено в разделе [Защита ключей](/docs/ru/rpc/protect-your-keys).

## Сравнение уровней защиты

| Уровень | Ключ в браузере? | Можно подделать? | Трудозатраты |
| - | - | - | - |
| Ключ с ограничением по доменам | Да | Заголовок Origin можно подделать | Минимальные |
| Безопасный RPC URL без ключа | В RPC нет ключа | Н/Д — ключа нет, частота ограничена | Нет (по умолчанию) |
| Серверный ключ (обработчик маршрута/Worker) | Нет | — | Низкие |
| Серверный ключ + IP/CIDR | Нет | Исходный IP-адрес **нельзя** подделать | Средние |

Какие бы уровни защиты вы ни выбрали, **ничто из этого не является ключами кошельков ваших пользователей** — они вообще не задействованы.

## Инициализация кошелька

<Note>
  При **рабочей настройке с обработчиком маршрута** инициализация кошелька
  (`/waas/config`) также выполняется через обработчик маршрута с **серверным**
  ключом, поэтому и в этом случае ключ Helius не передается в браузер. При настройке
  **прототипа** браузер отправляет ключ для инициализации;
  ограничьте его по доменам (шаг 1). В обоих случаях это ключ с областью действия RPC — он не может
  взаимодействовать с кошельками или средствами.
</Note>

## Контрольный список

Перед выпуском проверьте следующее:

* Клиентский ключ ограничен точными источниками ваших доменов
* Для локальной, промежуточной и рабочей сред используются отдельные ключи
* Ключ считывается из переменной окружения и никогда не прописывается непосредственно в коде
* (Необязательно) RPC, отправка и история направляются через бессерверный обработчик маршрута или Cloudflare Worker
* (Необязательно) Серверный ключ привязан к вашим IP-адресам/CIDR для создания неподделываемого ограничения

## Дальнейшие действия

<CardGroup cols={2}>
  <Card title="Protect your keys" icon="shield-halved" href="/docs/ru/rpc/protect-your-keys">
    Полный справочник по контролю доступа: домены, IP-адреса, CIDR и прокси.
  </Card>

  <Card title="Configuration" icon="sliders" href="/docs/ru/waas/configuration">
    Конфигурация провайдера и способы входа через панель управления.
  </Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.