> ## 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.

# Sichern Ihres Schlüssels

> Was der Helius-API-Schlüssel Ihrer eingebetteten Wallet-App kann und nicht kann und wie Sie ihn mit Zugriffskontrolle, sicheren RPC-URLs und einem Proxy absichern können.

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 [Turnkey](https://www.turnkey.com)s 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.

<Note>
  **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.
</Note>

## 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.

<Steps>
  <Step title="Öffnen Sie die RPC-Zugriffskontrolle">
    Gehen Sie im [Dashboard](https://dashboard.helius.dev) unter
    **RPCs** zu Ihrem Schlüssel und öffnen Sie **Zugriffskontrolle**.
  </Step>

  <Step title="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:

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

  <Step title="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.
  </Step>
</Steps>

<Note>
  **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](#4-fügen-sie-eine-nicht-fälschbare-ipcidr-grenze-hinzu)).
</Note>

### 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](/docs/de/sending-transactions/sender) 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.

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

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

* **Cloudflare Worker-Proxy** — die sauberste vollständig serverlose Option: Der Schlüssel lebt in einem Worker-Geheimnis und erreicht nie den Browser.

  <Card title="Helius RPC Proxy" icon="github" href="https://github.com/helius-labs/helius-rpc-proxy">
    Open-Source-RPC-Proxy, den Sie mit einem Klick auf Cloudflare bereitstellen können.
  </Card>

### 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**:

| Schlüssel                        | Verwendet von                         | Beschränkung           |
| -------------------------------- | ------------------------------------- | ---------------------- |
| Öffentlicher / Browser-Schlüssel | Anbieter `config` (Bootstrap)         | Erlaubte **Domains**   |
| Server-Schlüssel                 | Routen-Handler / Worker (RPC, Senden) | Erlaubte **IPs/CIDRs** |

<Note>
  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.
</Note>

Siehe [Schützen Sie Ihre Schlüssel](/docs/de/rpc/protect-your-keys) für die vollständige Referenz zu Zugriffskontrollregeln.

## Vergleich der Ebenen

| Ebene                                            | Schlüssel im Browser? | Fälschbar?                            | Aufwand          |
| ------------------------------------------------ | --------------------- | ------------------------------------- | ---------------- |
| Domain-beschränkter Schlüssel                    | Ja                    | Origin-Header ist fälschbar           | Niedrigst        |
| Sichere RPC-URL ohne Schlüssel                   | Kein Schlüssel in RPC | N/A — kein Schlüssel, rate-beschränkt | Keine (Standard) |
| Serverseitiger Schlüssel (Routen-Handler/Worker) | Nein                  | —                                     | Niedrig          |
| Serverseitiger Schlüssel + IP/CIDR               | Nein                  | Quell-IP ist **nicht** fälschbar      | Mittel           |

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

<Note>
  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.
</Note>

## 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

<CardGroup cols={2}>
  <Card title="Schützen Sie Ihre Schlüssel" icon="shield-halved" href="/docs/de/rpc/protect-your-keys">
    Vollständige Zugriffskontrollreferenz: Domains, IPs, CIDRs und Proxys.
  </Card>

  <Card title="Konfiguration" icon="sliders" href="/docs/de/waas/configuration">
    Anbieter-Konfiguration und Dashboard-Anmeldemethoden.
  </Card>
</CardGroup>