apiKey присутствует на стороне клиента: при загрузке приложения провайдер отправляет его в точку инициализации кошелька (/waas/config). Это ожидаемое поведение для клиентского SDK. На этой странице подробно объясняется, что этот ключ может и чего не может делать, а также как его защитить.
Что ключ может — и чего не может — делать
Начните с этого, поскольку здесь легко ошибиться: ключ Helius API — это учетные данные для RPC/кредитов, а не ключ кошелька. Утекший ключ не может:- подписывать транзакции или сообщения,
- перемещать средства или получать к ним доступ,
- взаимодействовать со встроенным кошельком любого пользователя.
Раскрытие ключа также не позволяет обойти оплату. Подписи WaaS учитываются в
момент подписания встроенным кошельком, а не на уровне ключа API — утекший ключ не
позволяет бесплатно создавать подписи или начислять оплату за подписи с чужого сайта. Учет
не зависит от секретности ключа.
Защитите ключ
Эти уровни перечислены от требующего меньше всего усилий до самого надежного ограничения. Первый уровень — обязательная основа; добавьте остальные в соответствии с допустимым для вас риском.1. Ограничьте ключ по доменам (обязательно)
Ограничьте ключ источниками, на которых работает ваше приложение, чтобы ключ, извлеченный из сборки, был бесполезен в других местах.1
Open RPC Access Control
На панели управления откройте свой ключ в разделе
RPCs, а затем откройте Access Control.
2
Add your domains to Allowed Domains
Добавьте каждый источник, с которого предоставляется ваше приложение: рабочую среду, промежуточную среду и среду предварительного просмотра:
3
Use a separate key per environment
Используйте отдельные ключи для локальной, промежуточной и рабочей сред, чтобы можно было заменить один ключ,
не нарушая работу остальных.
Списки разрешенных доменов предотвращают неправомерное использование в браузере, но не останавливают целенаправленный скрипт.
Проверка считывает заголовок
Origin/Referer запроса — браузер задает его
корректно, но небраузерный клиент (например, curl -H "Origin: yourdapp.com") может
его подделать. Это относится к любому клиентскому ключу API, а не только к Helius.
Ограничение по доменам надежно предотвращает распространенный сценарий — использование вашего ключа
на чужом сайте. Но если нужно ограничение, которое невозможно подделать, используйте
серверный ключ, привязанный к вашим IP-адресам/CIDR (шаг 4).2. Безопасные RPC URL без ключа (автоматически)
RPC-трафик вообще не содержит вашего ключа. Во время инициализации SDK получает безопасный RPC URL без ключа вашего проекта и автоматически использует его для вызововconnection — ничего настраивать не нужно.
Поскольку эти URL не содержат ключа, из RPC-запроса нечего извлекать. Для них также действует ограничение в 5 запросов в секунду на один IP-адрес, поэтому их защита не зависит от проверки Origin. (Доступно на платных тарифах; если у проекта нет безопасного RPC URL, RPC переключается на обработчик маршрута того же источника, описанный на шаге 3.)
3. Перенесите ключ на серверную сторону — без собственного сервера
Чтобы ключ не попадал в браузер при вызовах RPC, отправке и получении истории транзакций, направляйте эти вызовы через собственную конечную точку, которая добавляет ключ из серверного секрета. Таким же образом можно подключить оптимизированную через Sender отправку и историю транзакций. Оба варианта на 100% бессерверные — вам не нужно обслуживать сервер:-
Обработчик маршрута Next.js — развертывается как бессерверная функция (Vercel, Netlify, Cloudflare). Считывает
HELIUS_API_KEYиз серверного окружения.app/api/helius/[...path]/route.ts -
Прокси Cloudflare Worker — самый простой полностью бессерверный вариант: ключ хранится в секрете Worker и никогда не попадает в браузер.
Helius RPC Proxy
Прокси RPC с открытым исходным кодом, который можно развернуть в Cloudflare одним нажатием.
4. Добавьте неподделываемое ограничение по IP/CIDR
Чтобы создать ограничение, которое злоумышленник не сможет подделать, привяжите серверный ключ к IP-адресам или диапазонам CIDR вашего бэкенда. В отличие от заголовкаOrigin, исходный IP-адрес невозможно подделать при обычном подключении, поэтому curl, отправленный не с ваших серверов, будет сразу отклонен.
Это применимо только к серверному ключу: ограничить браузерный ключ по IP-адресам нельзя, поскольку пользователи подключаются с непредсказуемых IP-адресов. Рекомендуемая схема предполагает два ключа:
Бессерверные функции используют динамические исходящие IP-адреса, поэтому для привязки CIDR требуется
стабильный исходящий адрес — Cloudflare Worker с выделенным исходящим IP-адресом, Vercel Secure
Compute или NAT с фиксированным IP-адресом. Даже без этого вы получаете главное преимущество:
ключ находится на серверной стороне и никогда не попадает в браузер. Вы лишь не добавляете поверх этого
ограничение по IP-адресам.
Сравнение уровней защиты
Какие бы уровни защиты вы ни выбрали, ничто из этого не является ключами кошельков ваших пользователей — они вообще не задействованы.
Инициализация кошелька
При рабочей настройке с обработчиком маршрута инициализация кошелька
(
/waas/config) также выполняется через обработчик маршрута с серверным
ключом, поэтому и в этом случае ключ Helius не передается в браузер. При настройке
прототипа браузер отправляет ключ для инициализации;
ограничьте его по доменам (шаг 1). В обоих случаях это ключ с областью действия RPC — он не может
взаимодействовать с кошельками или средствами.Контрольный список
Перед выпуском проверьте следующее:- Клиентский ключ ограничен точными источниками ваших доменов
- Для локальной, промежуточной и рабочей сред используются отдельные ключи
- Ключ считывается из переменной окружения и никогда не прописывается непосредственно в коде
- (Необязательно) RPC, отправка и история направляются через бессерверный обработчик маршрута или Cloudflare Worker
- (Необязательно) Серверный ключ привязан к вашим IP-адресам/CIDR для создания неподделываемого ограничения
Дальнейшие действия
Protect your keys
Полный справочник по контролю доступа: домены, IP-адреса, CIDR и прокси.
Configuration
Конфигурация провайдера и способы входа через панель управления.