Zum Hauptinhalt springen
Das wallet-kit SDK läuft im Browser. Daher ist dein Helius apiKey clientseitig vorhanden: Der Provider sendet ihn beim Laden deiner App an den Wallet-Bootstrap (/waas/config). Das ist bei einem clientseitigen SDK zu erwarten. Diese Seite erklärt genau, was dieser API key tun kann und was nicht – und wie du ihn absicherst.

​
Was der API key tun kann – und was nicht

Beginne hier, denn dieser Punkt wird leicht missverstanden: Der Helius API key ist ein Zugangsnachweis für RPC und Credits, kein Wallet-Schlüssel. Ein offengelegter API key kann nicht:
  • Transaktionen oder Nachrichten signieren,
  • Guthaben verschieben oder darauf zugreifen oder
  • auf das eingebettete Wallet eines Benutzers zugreifen.
Das Signieren im Wallet wird durch den eigenen Passkey oder die eigene Sitzung des Endbenutzers autorisiert. Die privaten Schlüssel befinden sich in den sicheren Enklaven von Turnkey – niemals in deiner App, auf deinem Server oder in einem System, auf das der API key zugreifen kann. Das Offenlegen des API key legt keine Wallets offen. Ein offengelegter API key kann lediglich deine Helius Credits verbrauchen, also dein RPC-Kontingent. Das ist das gesamte Schadenspotenzial: Es betrifft die Abrechnung, nicht die Verwahrung. Die folgenden Schutzebenen begrenzen und schließen dieses Risiko.
Die Offenlegung umgeht auch nicht die Abrechnung. WaaS-Signaturen werden in dem Moment erfasst, in dem das eingebettete Wallet signiert, nicht auf der Ebene des API key. Ein offengelegter API key kann weder kostenlose Signaturen erzeugen noch Signaturen von der Website einer anderen Person abrechnen lassen. Die Erfassung hängt nicht von der Geheimhaltung des API key ab.

​
Sichere ihn ab

Diese Schutzebenen reichen vom geringsten Aufwand bis zur stärksten Abgrenzung. Die erste Ebene ist die erforderliche Grundlage. Ergänze je nach Risikotoleranz die weiteren Ebenen.

​
1. Beschränke deinen API key auf Domains (erforderlich)

Beschränke den API key auf die Origins, unter denen deine App läuft. So ist ein aus deinem Bundle ausgelesener API key an anderen Orten nutzlos.
1

Open RPC Access Control

Öffne im Dashboard deinen API key im Bereich RPCs und dann Access Control.
2

Add your domains to Allowed Domains

Füge jede Origin hinzu, über die du deine App bereitstellst – Produktion, Staging und Vorschau:
3

Use a separate key per environment

Verwende jeweils einen eigenen API key für lokale Entwicklung, Staging und Produktion. So kannst du einen davon rotieren, ohne die anderen Umgebungen außer Betrieb zu nehmen.
Domain-Zulassungslisten verhindern Missbrauch im Browser, aber nicht durch ein gezieltes Skript. Die Prüfung liest den Origin/Referer-Header des request. Ein Browser setzt ihn korrekt, aber ein Client außerhalb des Browsers, z. B. curl -H "Origin: yourdapp.com", kann ihn fälschen. Das gilt für jeden clientseitigen API key, nicht nur für Helius. Die Domain-Beschränkung verhindert zuverlässig den häufigsten Fall: Dein API key wird auf einer fremden Website verwendet. Wenn du eine Grenze brauchst, die sich nicht fälschen lässt, verwende einen serverseitigen API key, der auf deine IPs/CIDRs beschränkt ist (Schritt 4).

​
2. Sichere RPC-URLs ohne API key (automatisch)

RPC-Datenverkehr enthält deinen API key überhaupt nicht. Das SDK ruft beim Bootstrap die sichere RPC-URL ohne API key deines Projekts ab und verwendet sie automatisch für connection-Aufrufe. Du musst nichts konfigurieren. Da diese URLs keinen API key enthalten, lässt sich aus einem RPC-request nichts extrahieren. Außerdem gilt für sie ein rate limit von 5 RPS pro IP. Ihr Schutz hängt daher nicht von Origin-Prüfungen ab. Diese Funktion ist in kostenpflichtigen Tarifen verfügbar. Hat ein Projekt keine sichere RPC-URL, verwendet RPC stattdessen den Route Handler derselben Origin aus Schritt 3.

​
3. Verschiebe den API key auf die Serverseite – serverless

Damit der API key bei RPC-, Sende- und Transaktionsverlaufsaufrufen nicht im Browser landet, leitest du diese Aufrufe über deinen eigenen endpoint. Dieser fügt den API key aus einem serverseitigen Secret ein. Auf diese Weise aktivierst du auch die für Sender optimierte Transaktionsübermittlung und den Transaktionsverlauf. Beide Optionen sind zu 100 % serverless. Du musst keinen Server betreiben:
  • Next.js route handler – wird als serverless Funktion bereitgestellt, etwa über Vercel, Netlify oder Cloudflare. Liest HELIUS_API_KEY aus der Serverumgebung.
    app/api/helius/[...path]/route.ts
  • Cloudflare Worker proxy – die sauberste vollständig serverless Option: Der API key liegt in einem Worker Secret und erreicht niemals den Browser.

    Helius RPC Proxy

    Open-Source-RPC-proxy, den du mit einem Klick auf Cloudflare bereitstellst.

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

Für eine Grenze, die ein Angreifer nicht fälschen kann, beschränkst du einen serverseitigen API key auf die IP-Adressen oder CIDR-Bereiche deines Backends. Anders als ein Origin-Header lässt sich die Quell-IP eines request über eine normale Verbindung nicht fälschen. Daher wird ein Aufruf per curl von jedem anderen System als deinen Servern sofort abgelehnt. Das gilt nur für einen serverseitigen API key. Du kannst den API key im Browser nicht auf IPs beschränken, weil sich deine Benutzer über unvorhersehbare IPs verbinden. Das saubere Muster verwendet zwei API keys:
Serverless Funktionen verwenden dynamische ausgehende IPs. Um einen CIDR-Bereich festzulegen, brauchst du daher einen stabilen ausgehenden Netzwerkpfad, etwa einen Cloudflare Worker mit dedizierter ausgehender IP, Vercel Secure Compute oder ein NAT mit fester IP. Auch ohne eine solche Lösung erhältst du den wichtigsten Vorteil: Der API key liegt serverseitig und niemals im Browser. Du ergänzt lediglich keine zusätzliche IP-Grenze.
Unter API keys schützen findest du die vollständige Referenz zu den Regeln der Zugriffskontrolle.

​
Vergleich der Schutzebenen

Unabhängig davon, welche Schutzebenen du verwendest: Nichts davon betrifft die Wallet-Schlüssel deiner Benutzer. Sie spielen hierbei keine Rolle.

​
Der Wallet-Bootstrap

Bei der Produktionskonfiguration mit route handler läuft auch der Wallet-Bootstrap (/waas/config) mit dem serverseitigen API key über deinen route handler. Daher wird auch dafür kein Helius API key an den Browser ausgeliefert. Bei der Prototyp-Konfiguration sendet der Browser den API key für den Bootstrap. Beschränke ihn auf deine Domains (Schritt 1). In beiden Fällen ist es der auf RPC beschränkte API key. Er kann weder auf Wallets noch auf Guthaben zugreifen.

​
Checkliste

Vor der Veröffentlichung:
  • Der clientseitige API key ist auf deine exakten Origins beschränkt
  • Separate API keys für lokale Entwicklung, Staging und Produktion
  • Der API key wird aus einer Umgebungsvariable gelesen und niemals hardcodiert
  • (Optional) RPC-, Sende- und Verlaufsaufrufe laufen über den serverless route handler oder einen Cloudflare Worker
  • (Optional) Der serverseitige API key ist auf deine IPs/CIDRs beschränkt und bildet so eine nicht fälschbare Grenze

​
Nächste Schritte

Protect your keys

Vollständige Referenz zur Zugriffskontrolle: Domains, IPs, CIDRs und Proxys.

Configuration

Provider-Konfiguration und Anmeldemethoden im Dashboard.