apiKey está presente no lado do cliente: o provedor o envia para o bootstrap da carteira (/waas/config) quando seu aplicativo carrega. Isso é esperado para um SDK do lado do cliente. Esta página explica exatamente o que essa chave pode e não pode fazer, e como protegê-la.
O que a chave pode — e não pode — fazer
Comece aqui, porque é a parte que é fácil errar: a chave da API Helius é uma credencial de RPC/créditos, não uma chave de carteira. Uma chave vazada não pode:- assinar transações ou mensagens,
- mover ou acessar fundos, ou
- tocar em qualquer carteira incorporada do usuário.
A exposição também não é um desvio de cobrança. As assinaturas WaaS são medidas no
momento em que a carteira incorporada assina, não na camada de chave da API — uma chave vazada não pode
gerar assinaturas gratuitas ou cobrar assinaturas de outro site. A medição
não depende do sigilo da chave.
Proteja-a
Essas camadas vão do menor esforço até o limite mais difícil. A primeira é o padrão necessário; empilhe o restante conforme seu nível de tolerância ao risco exige.1. Restrinja sua chave a domínios (obrigatório)
Trave a chave nas origens em que seu aplicativo é executado, para que uma chave extraída de seu pacote seja inútil em qualquer outro lugar.1
Abrir Controle de Acesso RPC
No painel, vá para sua chave na
seção RPCs e abra o Controle de Acesso.
2
Adicione seus domínios a Domínios Permitidos
Adicione cada origem de onde seu aplicativo é servido — produção, staging e pré-visualização:
3
Use uma chave separada por ambiente
Mantenha uma chave distinta para local, staging e produção para que você possa rotacionar uma
sem derrubar as outras.
Listas de permissão de domínio impedem mau uso baseado em navegador, não um script determinado. O
teste lê o cabeçalho
Origin/Referer da solicitação — um navegador o configura
honestamente, mas um cliente não navegador (por exemplo, curl -H "Origin: yourdapp.com") pode
forjar. Isso é verdade para toda chave de API do lado do cliente, não apenas para Helius.
Restrição de domínio impede de forma confiável o caso comum — sua chave aparecendo em
outro site — mas para um limite que não pode ser forjado, use uma
chave do lado do servidor bloqueada para seus IPs/CIDRs (passo 4).2. URLs Secure RPC sem chave (automático)
O tráfego RPC não carrega sua chave. O SDK resolve a URL Secure RPC sem chave do seu projeto no bootstrap e a usa para chamadasconnection automaticamente — nada a configurar.
Como essas URLs não contêm nenhuma chave, não há nada em uma solicitação RPC para extrair, e elas são limitadas a 5 RPS por IP — então sua proteção não depende de verificações de origem. (Disponível em planos pagos; quando um projeto não tem URL Secure RPC, o RPC retorna ao manipulador de rota de mesma origem no passo 3.)
3. Mova a chave para o lado do servidor — serverless
Para manter a chave fora do navegador para chamadas de RPC, envio e histórico de transações, encaminhe-as por meio de seu próprio endpoint que injeta a chave de um segredo server-side. É assim que você opta por Sender-optimized landing e histórico de transações. Ambas as opções são 100% serverless — nenhum servidor para executar:-
Manipulador de rotas Next.js — implanta como função serverless (Vercel, Netlify, Cloudflare). Lê
HELIUS_API_KEYdo ambiente do servidor.app/api/helius/[...path]/route.ts -
Proxy Cloudflare Worker — a opção totalmente serverless mais limpa: a chave vive em um segredo do Worker e nunca chega ao navegador.
Helius RPC Proxy
Proxy RPC de código aberto que você implanta no Cloudflare com um clique.
4. Adicione um limite de IP/CIDR não forjável
Para um limite que um atacante não pode forjar, bloqueie uma chave server-side nos endereços IP ou intervalos CIDR do seu backend. Ao contrário de um cabeçalhoOrigin, o IP de origem de uma solicitação não pode ser forjado em uma conexão normal — então um curl de qualquer lugar, exceto seus servidores, é rejeitado de imediato.
Isso se aplica apenas a uma chave server-side — você não pode restringir o IP da chave do navegador, pois seus usuários se conectam a partir de IPs imprevisíveis. O padrão limpo é duas chaves:
Funções serverless têm IPs de saída dinâmicos, então fixar um CIDR requer um
saída estável — um Worker do Cloudflare com um IP de saída dedicado, Computação Segura da Vercel
ou um NAT com IP fixo na frente. Sem isso, você ainda obtém a principal vitória
(a chave é server-side, nunca no navegador); você só não adiciona o limite de IP
por cima.
Como as camadas se comparam
Quaisquer que sejam as camadas que você escolher, nada disso é das chaves de carteira dos seus usuários — aquelas nunca estão em jogo.
O bootstrap da carteira
Na configuração do manipulador de rota (produção), o bootstrap da carteira
(
/waas/config) também passa pelo seu manipulador de rota com a chave server-side
— então nenhuma chave Helius é enviada ao navegador para isso. Na
configuração de prototipagem, o navegador envia a chave para o bootstrap;
restrinja por domínio (passo 1). De qualquer forma, é a chave restrita a RPC — não pode
tocar em carteiras ou fundos.Lista de verificação
Antes de enviar:- A chave do cliente está restrita a domínios de suas origens exatas
- Chaves separadas para local / staging / produção
- A chave é lida de uma variável de ambiente, nunca codificada
- (Opcional) RPC, envio e histórico roteados pelo manipulador de rota serverless ou Worker do Cloudflare
- (Opcional) Chave server-side bloqueada para seus IPs/CIDRs para um limite não forjável
Próximos passos
Proteja suas chaves
Referência completa de controle de acesso: domínios, IPs, CIDRs e proxies.
Configuração
Configuração do provedor e métodos de login no painel.