Authentification et sécurité

API v2 : clé, liste blanche d’IP, HMAC

Modèle d’accès. Toutes les requêtes vers l’API v2 sont exécutées au nom d’une paire de clés
publicKey/secretKey.
Les clés sont créées dans le compte personnel ou via v1 (/api/v1/users/generate-api-key).

Restriction par IP. Lors de la création de la clé, indiquez les adresses de confiance dans
whiteListIp.
Les requêtes provenant de l’extérieur de cette liste sont rejetées.

Signature de chaque requête. Les en-têtes doivent inclure :

X-Api-Public-Key — votre publicKey

X-Api-Timestamp — chaîne d’horodatage (par ex., millisecondes epoch)

X-Api-Signature — signature HMAC-SHA256 en Base64

Formule de la signature

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

Où body — JSON sans espaces superflus (utilisez une sérialisation compacte).

Exemple (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

Deux modes d’accès. Une vérification manuelle via le support est possible — demander un accès permanent (fournir le projet, les volumes, la liste blanche d’IP, l’ID partenaire).

Authentification JWT. Obtenez des jetons via
POST /api/v1/users/local/authenticate (champs :
email, password, browserFingerprint).
Dans la réponse, le serveur définit des cookies :
session_id, access_token, refresh_token.

Exemple de requête (corps JSON)

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

Les jetons/cookies sont utilisés pour appeler les méthodes protégées de v1 et pour générer des clés d’API v2 via
/api/v1/users/generate-api-key.

Recommandations pour le stockage des clés et des jetons

Ne pas stocker dans le code/dépôt. Utilisez des variables d’environnement ou des gestionnaires de secrets (Vault, AWS Secrets Manager, GCP Secret Manager, etc.).

Séparer les environnements. Clés distinctes pour dev/stage/prod. Pour dev —
whiteListIp limité et permissions réduites.

Minimiser la surface d’attaque. Exécutez les requêtes vers v2 uniquement depuis le backend, ne générez jamais les clés et le HMAC côté frontend.

Rotation régulière. Réémettez périodiquement les clés, supprimez celles non utilisées
(/api/v1/users/list-api-key, /api/v1/users/delete-api-key).

Journalisation sans secrets. N’enregistrez pas
secretKey, les jetons ni les en-têtes d’autorisation complets ; journalisez uniquement des hachages/ID et les codes de réponse.

TLS partout. Utilisez uniquement
https. Refusez les redirections vers des schémas non sécurisés.

Cookies sécurisés. Pour v1, utilisez les indicateurs
HttpOnly, Secure ; stockez les jetons uniquement dans des conteneurs de session protégés.

Gestion des erreurs et nouvelles tentatives. En cas de 429/5xx — utilisez un backoff exponentiel. Vérifiez le corps de la réponse et la validité des paramètres obligatoires.

Principe du moindre privilège. Fournissez les clés et jetons aux services strictement là où ils sont nécessaire