Security Best Practices

​

API key management

• One key per application: Do not share a single API key across multiple applications or services. If one application is compromised, revoke the compromised key without affecting other applications.
• Minimal permissions: Assign the minimum permission set required:
  • Info + Trading — for applications that only read data and place trades
  • Info + Trading + Deposit + Withdraw — only for applications that need to move funds
• No client-side keys: Never embed API secrets in client-side code (browser JavaScript, mobile apps). API secrets must remain server-side only.
• Environment isolation: Use separate API keys for each application or service (e.g., one for the trading bot, one for the monitoring dashboard, one for the withdrawal service).

​

IP whitelisting

• Each API key supports up to 50 IP addresses in the whitelist
• Configure the whitelist in the API key settings at whitebit.com/settings/api
• Production recommendation: Always enable IP whitelisting for production API keys
• If the application runs on dynamic infrastructure (e.g., autoscaling), whitelist the NAT gateway or load balancer IP range
• IP whitelisting is the primary defense against stolen API credentials

​

Secret storage

• Environment variables: Store the API secret in an environment variable (e.g., WHITEBIT_API_SECRET); load at runtime
• Secrets managers: For production deployments, use a dedicated secrets manager (AWS Secrets Manager, HashiCorp Vault, GCP Secret Manager, Azure Key Vault)
• Never commit secrets: Add API key files and .env files to .gitignore
• No hardcoded secrets: Secrets must not appear in source code, configuration files committed to version control, Docker images, or CI/CD logs

​

Key rotation

• Auto-deactivation: API keys that remain unused for 14 consecutive days are automatically deactivated
• Rotation strategy:
  1. Create a new API key with the same permissions and IP whitelist
  2. Update the application configuration to use the new key
  3. Verify the application works with the new key
  4. Deactivate (delete) the old key
• Zero-downtime rotation: If the application supports multiple keys, configure the new key alongside the old key before deactivating the old one
• Monitor key activity to detect unauthorized usage patterns

​

Two-factor authentication

• 2FA must be enabled on the WhiteBIT account before creating API keys
• 2FA protects against unauthorized key creation even if account credentials are compromised
• Recommendation: use a hardware security key or authenticator app (not SMS)

​

Webhook HMAC verification

1. Read the raw request body
2. Base64-encode the body — compare with the X-TXC-PAYLOAD header
3. Compute HMAC_SHA512(base64_encoded_body, api_secret)
4. Convert to hex string — compare with the X-TXC-SIGNATURE header
5. If the signature does not match, reject the request (return non-200 status)

import hashlib
import hmac
import base64
from flask import Flask, request, jsonify

app = Flask(__name__)
WEBHOOK_SECRET = "YOUR_WEBHOOK_SECRET"

@app.route("/webhook", methods=["POST"])
def handle_webhook():
    raw_body = request.get_data()

    # Base64-encode the raw body
    encoded_payload = base64.b64encode(raw_body).decode()

    # Verify the payload header matches
    expected_payload = request.headers.get("X-TXC-PAYLOAD", "")
    if encoded_payload != expected_payload:
        return jsonify({"error": "Payload mismatch"}), 400

    # Compute the HMAC-SHA512 signature
    computed_signature = hmac.new(
        WEBHOOK_SECRET.encode(),
        encoded_payload.encode(),
        hashlib.sha512,
    ).hexdigest()

    # Compare with the signature header
    received_signature = request.headers.get("X-TXC-SIGNATURE", "")
    if not hmac.compare_digest(computed_signature, received_signature):
        return jsonify({"error": "Invalid signature"}), 401

    # Process the verified webhook
    data = request.get_json()
    print(f"Verified webhook: {data.get('method')} — ID: {data.get('id')}")
    return jsonify({"status": "ok"}), 200

​

Environment isolation