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

# Bảo mật khóa của bạn

> Khóa API Helius mà ứng dụng ví nhúng của bạn để lộ có thể và không thể làm gì, cũng như cách bảo vệ khóa bằng kiểm soát truy cập, URL RPC bảo mật và proxy.

SDK wallet-kit chạy trong trình duyệt, vì vậy `apiKey` Helius của bạn hiện diện ở phía máy khách: nhà cung cấp gửi khóa đó đến quy trình **khởi tạo** ví (`/waas/config`) khi ứng dụng tải. Đây là hành vi bình thường đối với SDK phía máy khách. Trang này giải thích chính xác khóa đó có thể và không thể làm gì, cũng như cách bảo vệ khóa.

## Khóa có thể — và không thể — làm gì

Hãy bắt đầu từ đây vì phần này rất dễ bị hiểu sai: **khóa API Helius là thông tin xác thực cho RPC/tín dụng, không phải khóa ví.**

Khóa bị rò rỉ **không thể**:

* ký giao dịch hoặc thông điệp,
* di chuyển hoặc truy cập tiền, hay
* can thiệp vào ví nhúng của bất kỳ người dùng nào.

Việc ký bằng ví được cho phép bởi **passkey hoặc phiên của chính người dùng cuối**, còn khóa riêng nằm trong các enclave bảo mật của [Turnkey](https://www.turnkey.com) — không bao giờ nằm trong ứng dụng, máy chủ của bạn hay bất kỳ nơi nào mà khóa API có thể truy cập. **Việc để lộ khóa không làm lộ ví.**

Điều mà khóa bị rò rỉ **có thể** làm là tiêu thụ **tín dụng Helius** (hạn mức RPC) của bạn. Đó là toàn bộ phạm vi ảnh hưởng — vấn đề về thanh toán chứ không phải quyền lưu ký — và các lớp bên dưới sẽ giới hạn rồi loại bỏ rủi ro này.

<Note>
  **Việc để lộ khóa cũng không thể giúp vượt qua cơ chế thanh toán.** Chữ ký WaaS được đo lường tại
  thời điểm ví nhúng ký, không phải ở lớp khóa API — khóa bị rò rỉ không thể
  tạo chữ ký miễn phí hoặc tính phí chữ ký từ trang web của người khác. Cơ chế đo lường
  không phụ thuộc vào tính bí mật của khóa.
</Note>

## Bảo vệ khóa

Các lớp này được sắp xếp từ mức tốn ít công sức nhất đến ranh giới bảo vệ vững chắc nhất. Lớp đầu tiên là mức cơ sở bắt buộc; hãy kết hợp các lớp còn lại tùy theo mức chấp nhận rủi ro của bạn.

### 1. Giới hạn khóa theo miền (bắt buộc)

Giới hạn khóa ở các nguồn gốc mà ứng dụng chạy để khóa bị lấy từ gói mã của bạn không thể được sử dụng ở nơi khác.

<Steps>
  <Step title="Open RPC Access Control">
    Trong [bảng điều khiển](https://dashboard.helius.dev), hãy chuyển đến khóa của bạn trong phần
    **RPCs** rồi mở **Access Control**.
  </Step>

  <Step title="Add your domains to Allowed Domains">
    Thêm mọi nguồn gốc mà ứng dụng của bạn được cung cấp từ đó — môi trường sản xuất, thử nghiệm và xem trước:

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

  <Step title="Use a separate key per environment">
    Dùng khóa riêng cho môi trường cục bộ, thử nghiệm và sản xuất để có thể xoay vòng một khóa
    mà không làm gián đoạn các môi trường còn lại.
  </Step>
</Steps>

<Note>
  **Danh sách miền cho phép ngăn hành vi lạm dụng qua trình duyệt, nhưng không ngăn được một tập lệnh có chủ đích.** Cơ chế
  kiểm tra đọc tiêu đề `Origin`/`Referer` của yêu cầu — trình duyệt thiết lập tiêu đề này
  trung thực, nhưng máy khách không phải trình duyệt (ví dụ: `curl -H "Origin: yourdapp.com"`) có thể
  giả mạo tiêu đề. Điều này đúng với **mọi** khóa API phía máy khách, không chỉ Helius.
  Giới hạn theo miền ngăn chặn hiệu quả trường hợp phổ biến — khóa của bạn xuất hiện trên
  trang web của người khác — nhưng để có ranh giới *không thể* bị giả mạo, hãy dùng
  khóa phía máy chủ được giới hạn theo IP/CIDR của bạn ([bước 4](#4-thêm-ranh-giới-ipcidr-không-thể-giả-mạo)).
</Note>

### 2. URL RPC bảo mật không chứa khóa (tự động)

Lưu lượng RPC hoàn toàn không mang theo khóa của bạn. SDK phân giải **URL RPC bảo mật không chứa khóa** của dự án khi khởi tạo và tự động dùng URL đó cho các lệnh gọi `connection` — không cần cấu hình.

Vì các URL này **không chứa khóa**, nên yêu cầu RPC không có gì để trích xuất, đồng thời chúng bị **giới hạn ở 5 yêu cầu mỗi giây cho mỗi IP** — do đó, cơ chế bảo vệ không phụ thuộc vào việc kiểm tra Origin. (Có trong các gói trả phí; khi dự án không có URL RPC bảo mật, RPC sẽ chuyển về trình xử lý tuyến cùng nguồn gốc ở bước 3.)

### 3. Chuyển khóa sang phía máy chủ — không máy chủ

Để khóa không xuất hiện trong trình duyệt đối với các lệnh gọi RPC, gửi giao dịch và lịch sử giao dịch, hãy định tuyến chúng qua điểm cuối của riêng bạn. Điểm cuối này chèn khóa từ một bí mật **phía máy chủ**. Đây cũng là cách bật tính năng [đưa giao dịch lên chuỗi được tối ưu hóa cho Sender](/docs/vi/sending-transactions/sender) và lịch sử giao dịch.

Cả hai lựa chọn đều **hoàn toàn không máy chủ** — không cần vận hành máy chủ:

* **Trình xử lý tuyến Next.js** — được triển khai dưới dạng hàm không máy chủ (Vercel, Netlify, Cloudflare). Đọc `HELIUS_API_KEY` từ môi trường máy chủ.

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

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

* **Proxy Cloudflare Worker** — lựa chọn hoàn toàn không máy chủ gọn gàng nhất: khóa nằm trong bí mật của Worker và không bao giờ đến trình duyệt.

  <Card title="Helius RPC Proxy" icon="github" href="https://github.com/helius-labs/helius-rpc-proxy">
    Proxy RPC nguồn mở mà bạn có thể triển khai lên Cloudflare chỉ bằng một lần nhấp.
  </Card>

### 4. Thêm ranh giới IP/CIDR không thể giả mạo

Để tạo ranh giới mà kẻ tấn công **không thể giả mạo**, hãy giới hạn khóa **phía máy chủ** theo địa chỉ IP hoặc dải CIDR của hệ thống phụ trợ. Không giống tiêu đề `Origin`, **IP nguồn không thể bị giả mạo** qua kết nối thông thường — vì vậy, `curl` từ bất kỳ nơi nào ngoài máy chủ của bạn đều bị từ chối ngay lập tức.

Cách này chỉ áp dụng cho khóa **phía máy chủ** — bạn không thể giới hạn khóa trình duyệt theo IP vì người dùng kết nối từ các IP không thể dự đoán. Mô hình rõ ràng nhất là dùng **hai khóa**:

| Khóa                         | Được sử dụng bởi                      | Giới hạn              |
| ---------------------------- | ------------------------------------- | --------------------- |
| Khóa công khai / trình duyệt | `config` của nhà cung cấp (khởi tạo)  | **Miền** được phép    |
| Khóa máy chủ                 | trình xử lý tuyến / Worker (RPC, gửi) | **IP/CIDR** được phép |

<Note>
  Các hàm không máy chủ có **IP đầu ra động**, vì vậy việc cố định CIDR cần một
  đầu ra ổn định — Cloudflare Worker có IP đầu ra chuyên dụng, Vercel Secure
  Compute hoặc NAT có IP cố định ở phía trước. Nếu không có, bạn vẫn nhận được lợi ích chính
  (khóa nằm ở phía máy chủ, không bao giờ ở trong trình duyệt); chỉ là bạn không thể bổ sung
  ranh giới IP bên trên.
</Note>

Xem [Bảo vệ khóa của bạn](/docs/vi/rpc/protect-your-keys) để biết tài liệu tham khảo đầy đủ về các quy tắc kiểm soát truy cập.

## So sánh các lớp

| Lớp                                          | Khóa trong trình duyệt? | Có thể giả mạo?                                   | Công sức         |
| -------------------------------------------- | ----------------------- | ------------------------------------------------- | ---------------- |
| Khóa được giới hạn theo miền                 | Có                      | Tiêu đề Origin có thể bị giả mạo                  | Thấp nhất        |
| URL RPC bảo mật không chứa khóa              | Không có khóa trong RPC | Không áp dụng — không có khóa, bị giới hạn tốc độ | Không (mặc định) |
| Khóa phía máy chủ (trình xử lý tuyến/Worker) | Không                   | —                                                 | Thấp             |
| Khóa phía máy chủ + IP/CIDR                  | Không                   | IP nguồn **không** thể bị giả mạo                 | Trung bình       |

Dù chọn lớp nào, **không có nội dung nào ở đây liên quan đến khóa ví của người dùng** — những khóa đó hoàn toàn không tham gia.

## Quy trình khởi tạo ví

<Note>
  Trong **thiết lập trình xử lý tuyến (sản xuất)**, quy trình khởi tạo ví
  (`/waas/config`) cũng đi qua trình xử lý tuyến cùng khóa **phía máy chủ**
  — vì vậy không có khóa Helius nào được gửi đến trình duyệt. Trong thiết lập
  **tạo nguyên mẫu**, trình duyệt gửi khóa để khởi tạo;
  hãy giới hạn khóa theo miền (bước 1). Dù theo cách nào, đây vẫn là khóa có phạm vi RPC — khóa không thể
  can thiệp vào ví hoặc tiền.
</Note>

## Danh sách kiểm tra

Trước khi phát hành:

* Khóa máy khách được giới hạn theo đúng các nguồn gốc của bạn
* Dùng khóa riêng cho môi trường cục bộ / thử nghiệm / sản xuất
* Khóa được đọc từ biến môi trường, tuyệt đối không được mã hóa cứng
* (Không bắt buộc) RPC, hoạt động gửi và lịch sử được định tuyến qua trình xử lý tuyến không máy chủ hoặc Cloudflare Worker
* (Không bắt buộc) Khóa phía máy chủ được giới hạn theo IP/CIDR để tạo ranh giới không thể giả mạo

## Các bước tiếp theo

<CardGroup cols={2}>
  <Card title="Protect your keys" icon="shield-halved" href="/docs/vi/rpc/protect-your-keys">
    Tài liệu tham khảo đầy đủ về kiểm soát truy cập: miền, IP, CIDR và proxy.
  </Card>

  <Card title="Configuration" icon="sliders" href="/docs/vi/waas/configuration">
    Cấu hình nhà cung cấp và các phương thức đăng nhập vào bảng điều khiển.
  </Card>
</CardGroup>