Аутентификация и безопасность

Author profile photo
Команда Quickex
24 августа 2025 г.
~2 мин. чтения

Аутентификация и безопасность

API v2: ключ, IP whitelist, HMAC

Модель доступа. Все запросы к API v2 выполняются от имени пары ключей
publicKey/secretKey.
Ключи создаются в личном кабинете или через v1 (/api/v1/users/generate-api-key).

Ограничение по IP. При создании ключа укажите доверенные адреса в
whiteListIp.
Запросы извне этого списка отклоняются.

Подпись каждого запроса. В заголовках передаются:

X-Api-Public-Key — ваш publicKey

X-Api-Timestamp — строка-метка времени (например, миллисекунды epoch)

X-Api-Signature — подпись HMAC-SHA256 в Base64

Формула подписи

StrToSign = timestamp + body + publicKey
Signature = Base64( HMAC_SHA256(StrToSign, secretKey) )

Где body — JSON без лишних пробелов (используйте компактную сериализацию).

Пример (curl)

curl -X POST "https://quickex.io/api/v2/instruments/public/validate-address" \
  -H "Accept: application/json" \
  -H "Content-Type: application/json" \
  -H "X-Api-Public-Key: {PUBLIC_KEY}" \
  -H "X-Api-Timestamp: {TIMESTAMP_MS}" \
  -H "X-Api-Signature: {HMAC_BASE64}" \
  -d '{"currencyTitle":"USDT","networkTitle":"TRC20","address":"..."}'

API v1: JWT/session

Два пути доступа. Возможна ручная верификация через поддержку — оформить постоянный доступ (передать проект, объёмы, whitelist IP, партнёрский ID).

JWT-аутентификация. Получите токены через
POST /api/v1/users/local/authenticate (поля:
email, password, browserFingerprint).
В ответе сервер устанавливает cookies:
session_id, access_token, refresh_token.

Пример запроса (тело JSON)

{
  "email": "user@example.com",
  "password": "yourpassword",
  "browserFingerprint": "unique-browser-id"
}

Токены/куки используются для вызовов защищённых методов v1 и для генерации API-ключей v2 через
/api/v1/users/generate-api-key.

Рекомендации по хранению ключей и токенов

Не хранить в коде/репозитории. Используйте переменные окружения или секрет-хранилища (Vault, AWS Secrets Manager, GCP Secret Manager и т.п.).

Разделять окружения. Отдельные ключи для dev/stage/prod. Для dev — ограниченный
whiteListIp и суженные права.

Минимизировать поверхность атаки. Запросы к v2 выполняйте только с бэкенда, ключи и HMAC никогда не генерируйте на фронтенде.

Регулярная ротация. Периодически перевыпускайте ключи, удаляйте неиспользуемые
(/api/v1/users/list-api-key, /api/v1/users/delete-api-key).

Логирование без секретов. В логах не писать
secretKey, токены и полные заголовки авторизации; логируйте только хэши/идентификаторы и коды ответа.

TLS везде. Используйте только
https. Отклоняйте перенаправления на небезопасные схемы.

Защищённые cookie. Для v1 используйте
HttpOnly, Secure флаги; сохраняйте токены только в защищённых контейнерах сессии.

Обработка ошибок и ретраи. При 429/5xx — экспоненциальный backoff. Проверяйте тело ответа и корректность обязательных параметров.

Доступ по принципу наименьших прав. Ключи и токены выдавайте сервисам ровно там, где они нужны; не делитесь ими между командами/микросервисами без необходимости.

Поделиться статьей: