Skip to main content
Das Wallet-Kit-SDK läuft im Browser, daher ist Ihr Helius apiKey clientseitig vorhanden: Der Anbieter sendet ihn beim Laden Ihrer App an den Wallet-Bootstrap (/waas/config). Dies wird für ein clientseitiges SDK erwartet. Diese Seite erklärt genau, was dieser Schlüssel kann und nicht kann, und wie Sie ihn absichern.

​
Was der Schlüssel kann — und nicht kann

Fangen Sie hier an, denn das ist der Teil, der leicht falsch gemacht werden kann: Der Helius-API-Schlüssel ist ein RPC/credits-Anmeldedaten, kein Wallet-Schlüssel. Ein geleakter Schlüssel kann nicht:
  • Transaktionen oder Nachrichten signieren,
  • Geldmittel bewegen oder darauf zugreifen oder
  • auf das eingebettete Wallet eines Benutzers zugreifen.
Das Signieren von Wallets wird durch den eigenen Zugangsschlüssel oder die Sitzung des Endbenutzers autorisiert, und die privaten Schlüssel befinden sich in Turnkeys sicheren Enklaven — niemals in Ihrer App, Ihrem Server oder in irgendetwas, worauf der API-Schlüssel zugreifen kann. Das Offenlegen des Schlüssels setzt keine Wallets aus. Was ein geleakter Schlüssel kann, ist, Ihre Helius-Credits (RPC-Kontingent) zu verbrauchen. Das ist der gesamte Wirkungsbereich — es geht um Abrechnung, nicht um Verwahrung — und die folgenden Ebenen begrenzen und schließen ihn.
Auch die Offenlegung ist kein Abrechnungs-Bypass. WaaS-Signaturen werden in dem Moment gemessen, in dem das eingebettete Wallet signiert, nicht auf der API-Schlüsselschicht — ein geleakter Schlüssel kann keine kostenfreien Signaturen erstellen oder Signaturen von einer anderen Website abrechnen. Die Messung hängt nicht von der Geheimhaltung des Schlüssels ab.

​
Absichern

Diese Ebenen reichen vom geringsten Aufwand bis zur härtesten Grenze. Die erste ist die erforderliche Basislinie; stapeln Sie den Rest nach Bedarf und Risikobereitschaft.

​
1. Beschränken Sie Ihren Schlüssel auf Domains (erforderlich)

Sichern Sie den Schlüssel auf die Ursprünge, auf denen Ihre App läuft, sodass ein aus Ihrem Bundle geschrappter Schlüssel von anderswo nutzlos ist.
1

Öffnen Sie die RPC-Zugriffskontrolle

Gehen Sie im Dashboard unter RPCs zu Ihrem Schlüssel und öffnen Sie Zugriffskontrolle.
2

Fügen Sie Ihre Domains zu den erlaubten Domains hinzu

Fügen Sie jeden Ursprung hinzu, von dem Ihre App bedient wird — Produktion, Staging und Vorschau:
3

Verwenden Sie einen separaten Schlüssel für jede Umgebung

Behalten Sie einen eigenen Schlüssel für lokal, Staging und Produktion, damit Sie einen rotieren können, ohne die anderen herunterzufahren.
Domain-Whitelist stoppt browserbasierte Missbräuche, nicht ein entschlossenes Skript. Die Überprüfung liest den Header Origin/Referer der Anfrage — ein Browser setzt ihn ehrlich, aber ein Nicht-Browser-Client (z. B. curl -H "Origin: yourdapp.com") kann ihn fälschen. Dies gilt für jeden clientseitigen API-Schlüssel, nicht nur Helius. Die Domain-Beschränkung stoppt zuverlässig den häufigen Fall — dass Ihr Schlüssel auf einer anderen Website erscheint — aber für eine Grenze, die nicht gefälscht werden kann, verwenden Sie einen serverseitigen Schlüssel, der auf Ihre IPs/CIDRs beschränkt ist (Schritt 4).

​
2. Sichere RPC-URLs ohne Schlüssel (automatisch)

Der RPC-Verkehr überträgt Ihren Schlüssel überhaupt nicht. Das SDK löst die schlüssellose sichere RPC-URL Ihres Projekts beim Bootstrap automatisch auf und verwendet sie für connection-Anrufe — es muss nichts konfiguriert werden. Da diese URLs keinen Schlüssel enthalten, gibt es nichts in einer RPC-Anfrage zu extrahieren, und sie sind auf 5 RPS pro IP begrenzt — ihre Schutz hängt also nicht von Origin-Überprüfungen ab. (Verfügbar in kostenpflichtigen Plänen; wenn ein Projekt keine sichere RPC-URL hat, fällt RPC auf den gleichnamigen Routen-Handler in Schritt 3 zurück.)

​
3. Verschieben Sie den Schlüssel serverseitig — serverlos

Um den Schlüssel aus dem Browser für RPC-, Sende- und Transaktionshistorie-Anrufe fernzuhalten, leiten Sie sie durch Ihren eigenen Endpunkt, der den Schlüssel aus einem serverseitigen Geheimnis einfügt. Dies ist auch der Weg, wie Sie sich für Sender-optimierten Empfang und Transaktionshistorie entscheiden. Beide Optionen sind 100 % serverlos — kein Server zu betreiben:
  • Next.js-Routen-Handler — wird als serverlose Funktion (Vercel, Netlify, Cloudflare) bereitgestellt. Liest HELIUS_API_KEY aus der Serverumgebung.
    app/api/helius/[...path]/route.ts
  • Cloudflare Worker-Proxy — die sauberste vollständig serverlose Option: Der Schlüssel lebt in einem Worker-Geheimnis und erreicht nie den Browser.

    Helius RPC Proxy

    Open-Source-RPC-Proxy, den Sie mit einem Klick auf Cloudflare bereitstellen können.

​
4. Fügen Sie eine nicht fälschbare IP/CIDR-Grenze hinzu

Für eine Grenze, die ein Angreifer nicht fälschen kann, sichern Sie einen serverseitigen Schlüssel auf die IP-Adressen oder CIDR-Bereiche Ihres Backends. Im Gegensatz zu einem Origin-Header kann eine Anforderungs-Quell-IP in einer normalen Verbindung nicht gefälscht werden — daher wird ein curl von überall außer Ihren Servern sofort abgelehnt. Dies gilt nur für einen serverseitigen Schlüssel — Sie können den Browser-Schlüssel nicht auf IPs beschränken, da Ihre Benutzer sich von unvorhersehbaren IPs verbinden. Die saubere Vorgehensweise sind zwei Schlüssel:
Serverlose Funktionen haben dynamische Ausgangs-IPs, daher erfordert das Fixieren einer CIDR einen stabilen Ausgang — einen Cloudflare-Worker mit einer dedizierten Ausgangs-IP, Vercel Secure Compute oder ein festes-IP-NAT vorne. Ohne diese erhalten Sie immer noch den Hauptvorteil (der Schlüssel ist serverseitig, nie im Browser); Sie fügen einfach die IP-Grenze nicht zusätzlich hinzu.
Siehe Schützen Sie Ihre Schlüssel für die vollständige Referenz zu Zugriffskontrollregeln.

​
Vergleich der Ebenen

Unabhängig von den gewählten Ebenen: Keine dieser Dinge betrifft die Schlüssel der Wallets Ihrer Benutzer — diese sind niemals betroffen.

​
Der Wallet-Bootstrap

Im Routen-Handler (Produktions-)Setup geht der Wallet-Bootstrap (/waas/config) ebenfalls durch Ihren Routen-Handler mit dem serverseitigen Schlüssel — sodass kein Helius-Schlüssel für ihn an den Browser übertragen wird. Im Prototyping-Setup sendet der Browser den Schlüssel für den Bootstrap; beschränken Sie ihn auf Domains (Schritt 1). So oder so ist es der RPC-beschränkte Schlüssel — er kann keine Wallets oder Gelder berühren.

​
Checkliste

Bevor Sie versenden:
  • Client-Schlüssel ist auf Ihre genauen Ursprünge beschränkt
  • Separate Schlüssel für lokal / Staging / Produktion
  • Schlüssel wird aus einer Env-Variable gelesen, niemals hartcodiert
  • (Optional) RPC, Senden und Historie über den serverlosen Routen-Handler oder Cloudflare Worker geleitet
  • (Optional) Serverseitiger Schlüssel, der auf Ihre IPs/CIDRs festgelegt ist, für eine nicht fälschbare Grenze

​
Nächste Schritte

Schützen Sie Ihre Schlüssel

Vollständige Zugriffskontrollreferenz: Domains, IPs, CIDRs und Proxys.

Konfiguration

Anbieter-Konfiguration und Dashboard-Anmeldemethoden.