API Hop

Tài liệu

Tài liệu API Hop

Bảo mật và cấu hình

Tạo khóa API, kiểm soát quyền, luân chuyển khóa và thực hành bảo mật.

Nguyên tắc cốt lõi bảo vệ khóa API: không để lộ, dùng quyền tối thiểu, luân chuyển định kỳ và giữ khả năng truy nguyên sử dụng.

Tôi nên quản lý và bảo vệ khóa API thế nào?

Thực hành khuyến nghị:

  • Không đưa khóa API vào kho mã công khai, trang giao diện, gói ứng dụng di động hoặc ảnh chụp màn hình.
  • Đọc khóa API từ biến môi trường hoặc trình quản lý bí mật trên máy chủ.
  • Tạo khóa API riêng cho phát triển, kiểm thử và sản xuất.
  • Tạo khóa riêng cho dịch vụ hoặc ứng dụng khác nhau để cải thiện truy nguyên và cách ly.
  • Cấu hình quyền mô hình theo nhu cầu và đặt ngày hết hạn khi phù hợp.
  • Luân chuyển khóa API định kỳ; đổi ngay sau thay đổi nhân sự, dừng dịch vụ hoặc nghi ngờ rò rỉ.

Nếu khóa API có thể đã lộ:

  1. Vô hiệu hóa, xóa hoặc luân chuyển khóa cũ ngay.
  2. Tạo khóa mới và cập nhật mọi dịch vụ phụ thuộc.
  3. Xem mức sử dụng gần đây, thay đổi số dư và chi tiêu bất thường.
  4. Thu hẹp quyền mô hình và cân nhắc thời hạn ngắn hơn.
  5. Rà soát đường rò rỉ như kho mã, nhật ký, cấu hình CI hoặc máy khách bên thứ ba.

Lộ khóa API có thể gây lời gọi trái phép và thiệt hại chi phí. Ngay cả khóa thử nghiệm cũng nên bảo vệ như bí mật sản xuất.

Tôi có xem lại khóa API đầy đủ sau khi tạo được không?

Không. Khóa API đầy đủ chỉ hiển thị trong luồng tạo thành công. Bảng điều khiển sau đó chỉ hiển thị bản xem trước đã che.

Trước khi đóng hộp thoại tạo, lưu khóa vào biến môi trường phía máy chủ hoặc trình quản lý bí mật. Khóa bị mất không thể khôi phục qua API người dùng hay quản trị viên. Tạo khóa thay thế, cập nhật bên gọi, rồi xóa khóa cũ. Mẫu tích hợp AI trong tài liệu dùng chỗ giữ <API_KEY> và không tải khóa trước đây.

Tôi nên gửi khóa API thế nào?

Chỉ gửi khóa API trong tiêu đề yêu cầu. Chúng tôi khuyên dùng:

http
Authorization: Bearer YOUR_API_KEY

Bạn cũng có thể dùng:

http
X-API-Key: YOUR_API_KEY

Không bao giờ đặt thông tin xác thực API API Hop trong truy vấn URL. Tên kiểu thông tin xác thực (apiKey, api_key, apikey, x-api-key và key) thường gây HTTP 400. Ngoại lệ hẹp cho tham số nghiệp vụ Similarweb chỉ áp dụng với yêu cầu GET: /v1/similarweb/websites/backlinks nhận một tên máy chủ Key viết hoa; /v1/similarweb/websites/outgoing-traffic, /websites/incoming-referrals và /websites/similar-sites/suggestions nhận một tên máy chủ key viết thường (tất cả dưới /v1/similarweb). Các trường xác định website đích, không phải thông tin xác thực API. Tên máy chủ phải hợp lệ. Mục trùng, sai kiểu chữ, giá trị giống thông tin xác thực và trường truy vấn xác thực bổ sung vẫn bị chặn. Luôn xác thực bằng tiêu đề yêu cầu, kể cả trên tuyến Similarweb. Xem ví dụ yêu cầu Similarweb.

Quy tắc này không ảnh hưởng tham số nghiệp vụ khác như OAuth token, apiKeyId, username hoặc pagination_token.