Bezpieczeństwo i konfiguracja

Podstawowe zasady ochrony kluczy API: nie ujawniaj ich, stosuj minimalne uprawnienia, regularnie rotuj i zapewnij identyfikowalność użycia.

Jak zarządzać kluczami API i je chronić?

Zalecane praktyki:

• Nie umieszczaj kluczy API w publicznych repozytoriach, stronach interfejsu, pakietach aplikacji mobilnych ani zrzutach ekranu.
• Odczytuj klucze API ze zmiennych środowiskowych lub menedżera sekretów na serwerze.
• Twórz osobne klucze API do programowania, testowania i produkcji.
• Twórz osobne klucze dla różnych usług lub aplikacji, aby poprawić identyfikowalność i izolację.
• Konfiguruj uprawnienia do modeli według potrzeb i ustawiaj odpowiednie daty wygaśnięcia.
• Regularnie rotuj klucze API; rób to natychmiast po zmianach personelu, wyłączeniu usługi lub podejrzeniu wycieku.

Jeśli klucz API mógł wyciec:

1. Natychmiast wyłącz, usuń lub wymień stary klucz.
2. Utwórz nowy klucz i zaktualizuj wszystkie zależne usługi.
3. Przejrzyj ostatnie zużycie, zmiany salda i nietypowe wydatki.
4. Ogranicz uprawnienia do modeli i rozważ krótszy termin ważności.
5. Sprawdź drogę wycieku, na przykład repozytoria, logi, konfigurację CI lub klientów zewnętrznych.

Wyciek klucza API może powodować nieautoryzowane wywołania i straty finansowe. Nawet klucze testowe należy chronić jak sekrety produkcyjne.

Czy po utworzeniu mogę ponownie zobaczyć pełny klucz API?

Nie. Pełny klucz API jest pokazywany tylko w procesie pomyślnego utworzenia. Później konsola wyświetla jedynie zamaskowany podgląd.

Przed zamknięciem okna tworzenia zapisz klucz w zmiennej środowiskowej serwera lub menedżerze sekretów. Utraconego klucza nie można odzyskać przez API użytkownika ani administratora. Utwórz zamiennik, zaktualizuj wywołującego, a następnie usuń stary klucz. Szablon integracji AI dokumentacji używa symbolu <API_KEY> i nie ładuje historycznych kluczy.

Jak wysyłać klucz API?

Wysyłaj klucze API wyłącznie w nagłówkach żądań. Zalecamy:

Authorization: Bearer YOUR_API_KEY

Możesz też użyć:

X-API-Key: YOUR_API_KEY

Nigdy nie umieszczaj danych uwierzytelniających API API Hop w zapytaniu URL. Nazwy przypominające dane uwierzytelniające (apiKey, api_key, apikey, x-api-key i key) zwykle powodują HTTP 400. Wąskie wyjątki dla parametrów biznesowych Similarweb dotyczą tylko żądań GET: /v1/similarweb/websites/backlinks przyjmuje jedną nazwę hosta w Key z wielką literą; /v1/similarweb/websites/outgoing-traffic, /websites/incoming-referrals i /websites/similar-sites/suggestions przyjmują jedną nazwę hosta w key z małą literą (wszystkie pod /v1/similarweb). Te pola wskazują witrynę docelową, a nie dane uwierzytelniające API. Nazwy hostów muszą być poprawne. Duplikaty, błędna wielkość liter, wartości przypominające dane uwierzytelniające i dodatkowe pola uwierzytelnienia w zapytaniu pozostają blokowane. Zawsze uwierzytelniaj nagłówkiem żądania, również na trasach Similarweb. Zobacz przykład żądania Similarweb.

Ta reguła nie wpływa na inne parametry biznesowe, takie jak OAuth token, apiKeyId, username lub pagination_token.