If you run any kind of automated trading — a simple rebalancing script, a grid bot, or a full strategy engine — you cannot avoid the exchange API key. It is the credential that lets your code move money. Functionally, it belongs to the same family as a database password or a cloud account key, and it deserves the same discipline: grant the minimum permission necessary, and nothing more.

This guide translates the common-sense engineering practices around API keys into the specific context of crypto exchanges, and expands on the basics with the details that actually get skipped — rotation, multi-key segmentation, and what real-world breaches look like when these controls are missing. It contains no real keys and no platform-specific click-through instructions; for the latter, defer to your exchange’s own documentation.

TL;DR

  • Scope every key to the narrowest permission it needs; never enable withdrawal.
  • Keep keys out of source control. Git history is permanent.
  • Prefer environment variables for local work and a secrets manager for production.
  • Restrict each key to a fixed IP allowlist.
  • Never log keys — not in debug output, not in stack traces.
  • Rotate on a schedule (60–90 days) and immediately on any suspicion of exposure.
  • If a key leaks: revoke first, investigate second.

The principle: least privilege

Exchange API keys are almost always tiered. The three permissions you will see most often are:

  • Read-only — view balances, positions, and history. Cannot place orders or move funds.
  • Trade — place and cancel orders on spot, margin, or futures.
  • Withdraw — pull assets out of the exchange to an external address.

The rule is straightforward: give the program only what it needs to do its job. A portfolio tracker or a tax-reporting script should run on a read-only key. A trading bot needs trade access — but it has no legitimate reason to withdraw, so leave the withdrawal permission off entirely. If a key is ever leaked, the worst case is then bounded to trading activity on the account, not a direct drain of funds. [1]

Segmenting by function also limits the blast radius. Rather than one all-powerful key, create separate keys for separate jobs — one read-only key for monitoring, one trade-only key for the bot — so that a compromise of any single key cannot do everything. [1]

Storage: keep keys out of the repository

The most common way API keys leak is also the most avoidable: they get committed to a code repository.

A secret removed from the latest file is not removed from history. It lives in every past commit and in every clone. Anyone with repository access — or access to a fork, a backup, or a leaked archive — can recover it. Treat any key that has ever touched version control as compromised and rotate it. [3]

The safer patterns:

  • Don’t hardcode. Never embed keys directly in source files, client-side JavaScript, mobile binaries, or build artifacts — anything shipped to a browser should be considered public.
  • Use a secrets manager or environment variables. For local development, read keys from an environment variable or an ignored .env file. For production, use a platform secret store (for example HashiCorp Vault, AWS Secrets Manager, or Azure Key Vault), which adds access control, audit logging, and automatic rotation. [3]
  • Commit only samples. Keep a .env.example with placeholder values in the repo; put the real .env in .gitignore before the first commit.
  • Restrict by IP. Apply an IP allowlist to every key so that even a stolen credential cannot be used from an unrecognized network. Most major exchanges support this as a standard feature, and some even require it before enabling withdrawals. [1][2]

One subtlety worth internalizing: environment variables are a delivery mechanism, not secure storage. Any process running as the same user can read them, crash dumps can log them, and child processes inherit them. They are a meaningful improvement over hardcoding, but for anything serious, a vault is the real end state. [3]

Logging hygiene: the silent leak

Logging is where keys quietly escape. Debug output and error handlers often print request headers, configuration objects, or full environment dumps — exactly the places a key can hide. Before shipping, walk through every log statement and every exception path and confirm none of them can emit a credential. [3]

The same caution applies to screenshots, CI logs, and support tickets. A key pasted into a chat or a bug report persists according to your workspace’s backup and retention policy, far beyond the moment you “deleted” it.

Rotation and lifecycle

The original write-up deliberately left this out; it is too important to skip.

Treat key rotation as routine maintenance. A common baseline is to rotate every 60 to 90 days for keys in active use. Keys created for one-time jobs — say, a single tax data import — should be deleted the moment they are no longer needed. [1]

The rotation procedure for a planned change is: create the replacement key, update the application to use it, verify it works, then revoke the old key. For a suspected compromise, skip the graceful overlap: revoke immediately and follow incident response instead. [3]

The account layer: 2FA and subaccounts

API keys are not the only surface. The exchange account itself should be protected so that an attacker who gains API access still cannot change settings, mint new keys, or add withdrawal addresses without a second factor. [2]

  • Use an authenticator app or hardware key, not SMS. SMS-based 2FA is vulnerable to SIM-swapping, where an attacker convinces a carrier to move your number to a SIM they control. [2]
  • Run bots on subaccounts with limited balances. A subaccount contains the blast radius: if a bot or its key is compromised, the damage is capped at the subaccount’s balance rather than your main account. [1]
  • Whitelist withdrawal addresses. Even where API withdrawals are possible, address whitelists add a waiting period and an approval step that can block transfers to unknown destinations. [2]

When controls are missing: two real cases

Abstract advice lands harder with concrete failures. Two documented incidents show what happens when the basics above are absent.

A malicious extension that forged the UI. In 2025, security researchers disclosed a Chrome extension, “MEXC API Automator,” that masqueraded as a trading tool. When a user visited the exchange’s API management page, the extension programmatically created a new API key, enabled withdrawal permission, and then hid that permission in the user interface so the checkbox appeared disabled. The generated key and secret were exfiltrated to a Telegram bot under the attacker’s control. The danger persisted even after the extension was uninstalled, because the key itself stayed valid. [4]

The lesson is unsettling: a credential with withdrawal rights, created inside a trusted session and concealed from view, can drain an account without the user’s password or a bypass of 2FA. The UI is not proof of the backend state.

A $340K loss through a deepfake and an unrevoked key. In another reported case, an attacker used an AI-generated deepfake video to pass the exchange’s KYC, reset the victim’s email and phone, and — while in control — create an API key with withdrawal permissions. The exchange later froze the account and restored the user’s login, but did not revoke the malicious API key. When a standard 24-hour withdrawal hold expired, the key executed six transactions and moved roughly $340,000 out, with no new login recorded. [5]

The takeaway: account recovery must include the API layer. Restoring a password does nothing if a live, withdrawal-enabled key remains. Revoke every key after any security incident, without exception. [5]

Incident response: stop the bleed first

If you suspect a key has leaked, the order matters:

  1. Revoke or reset the key on the exchange immediately. This is the first step — cut access before anything else.
  2. Audit recent activity. Check for unauthorized trades or withdrawals while the key was live.
  3. Investigate the source. Was it a committed file, a phishing page, a compromised device, or a malicious dependency? You cannot prevent a repeat until you know how it happened.
  4. Only regenerate after the root cause is understood. Issuing a fresh key into the same hole just reopens the door.

Relying on memory for any of this is fragile. The most durable approach is to write key management as a fixed checklist and run through it on every deployment. [1]

A deployable checklist

  • Every key scoped to the minimum permission; withdrawal disabled unless explicitly required and isolated.
  • No key in source, config, client code, or build artifacts; .env in .gitignore.
  • Production keys in a secrets manager with audit logging.
  • IP allowlist applied to every key.
  • No key in any log line, exception, screenshot, or ticket.
  • Rotation schedule defined (60–90 days); immediate rotation on suspicion.
  • Account protected by app-based or hardware 2FA; bots on balance-limited subaccounts.
  • Withdrawal address whitelist enabled.
  • Post-incident procedure: revoke → audit → investigate → regenerate.

Closing

The substance here is not exotic. Keys should be scoped to exactly what a program needs, kept out of repositories, never printed to logs, restricted by IP, and rotated on a schedule. The cases above show the cost when these are skipped — and the cost is measured in withdrawn balances, not in theory.

One caveat worth repeating: these are general engineering practices. They do not certify that any specific platform’s security model is sufficient, and they do not cover every edge — multi-party permission allocation for teams, for instance, deserves its own treatment. If a scenario genuinely requires broader permissions than “minimum,” that risk should be evaluated on its own terms rather than folded into a default. Automate the checklist, and let the checklist, not memory, be the guardrail.

References