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 để 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.
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.1
Open RPC Access Control
Trong bảng điều khiển, hãy chuyển đến khóa của bạn trong phần
RPCs rồi mở Access Control.
2
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:
3
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.
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).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ọiconnection — 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 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_KEYtừ môi trường máy chủ.app/api/helius/[...path]/route.ts -
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.
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.
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:
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.
So sánh các lớp
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í
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.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
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.
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.