Безопасность и настройка

Основные принципы защиты API-ключей: не раскрывать, выдавать минимальные права, регулярно менять и обеспечивать отслеживание использования.

Как управлять API-ключами и защищать их?

Рекомендации:

• Не помещайте ключи в публичные репозитории, клиентские страницы, мобильные пакеты или снимки экрана.
• Читайте ключи на сервере из переменных окружения или менеджера секретов.
• Создавайте отдельные ключи для разработки, тестирования и рабочей среды.
• Используйте разные ключи для сервисов и приложений ради отслеживаемости и изоляции.
• Настраивайте необходимые разрешения моделей и при необходимости сроки действия.
• Регулярно меняйте ключи; после смены сотрудников, отключения сервиса или подозрения утечки — немедленно.

При возможной утечке:

1. Немедленно отключите, удалите или замените старый ключ.
2. Создайте новый и обновите все зависимые сервисы.
3. Проверьте недавнее использование, изменения баланса и необычные расходы.
4. Сократите разрешения моделей и рассмотрите меньший срок действия.
5. Проверьте путь утечки: репозитории, журналы, настройки CI или сторонние клиенты.

Утечка может вызвать неразрешенные вызовы и финансовые потери. Даже тестовые ключи защищайте как рабочие секреты.

Можно ли снова увидеть полный API-ключ после создания?

Нет. Полный ключ показывается только при успешном создании. После этого консоль отображает лишь маскированный фрагмент.

Перед закрытием окна сохраните ключ в серверной переменной окружения или менеджере секретов. Потерянный ключ нельзя восстановить через пользовательские или административные API. Создайте замену, обновите вызывающую сторону и удалите старый ключ. Шаблон интеграции ИИ в документации использует <API_KEY> и не загружает прежние ключи.

Как передавать API-ключ?

Передавайте ключи только в заголовках. Рекомендуется:

Authorization: Bearer YOUR_API_KEY

Также можно использовать:

X-API-Key: YOUR_API_KEY

Никогда не помещайте учетные данные API RequestBeam в строку запроса URL. Имена, характерные для учетных данных (apiKey, api_key, apikey, x-api-key и key), обычно вызывают HTTP 400. Узкие исключения для бизнес-параметров Similarweb действуют только для GET: /v1/similarweb/websites/backlinks принимает одно имя хоста в поле Key с заглавной буквы; /v1/similarweb/websites/outgoing-traffic, /websites/incoming-referrals и /websites/similar-sites/suggestions принимают одно имя хоста в строчном поле key (все под /v1/similarweb). Поля обозначают целевой сайт, а не учетные данные API. Имя хоста должно быть допустимым. Дубликаты, неверный регистр, похожие на секреты значения и дополнительные поля учетных данных остаются заблокированы. Всегда аутентифицируйтесь заголовком запроса, в том числе на маршрутах Similarweb. См. пример запроса Similarweb.

Правило не затрагивает другие бизнес-параметры, например OAuth token, apiKeyId, username или pagination_token.