What Happens When an API Key Leaks: Permission Design and Least Privilege

When people picture an API key leak, they usually picture coins being withdrawn. That's rarely how it actually plays out. Withdrawal permission is usually switched off, so whoever has the key can't pull your coins out on-chain — but they can use your balance to make trades that benefit them, and they can shuffle money around between your own accounts. By the time you notice, the money is still in your account. There's just less of it.

This piece is about the mechanics and the consequences: what each of the three permission types means, what an attacker can and can't do once a key is out, which lock gives you the most protection for the effort, where keys usually leak from, and what order to handle things in once you find out. If you want a checklist you can tick through line by line, use the API security checklist; this article is the “why” behind that list.

The three permission types

Platforms name them a little differently, but the permissions you choose when creating an API key almost always fall into three buckets. From least to most dangerous:

Withdrawal permission should almost never be switched on. The reasoning is simple: automated trading doesn't need it. A strategy script buys and sells; it has no business moving coins out. You might be thinking “but what if I want a script that sweeps funds together automatically?” — even then, do it by hand. Once a key with withdrawal rights leaks, there's almost no window to recover: a single request sends your assets to the attacker's address, and on-chain transfers can't be reversed. The few manual steps you save aren't worth that risk.

One more thing worth flagging: on some platforms, withdrawal permission only really takes effect together with a withdrawal address whitelist, and the rules vary from platform to platform. But “I've set an address whitelist, so I'm safe” is a dangerous oversimplification — the whitelist is itself an account setting, and whether it can be changed, and whether a change comes with a cooling-off period, depends on the platform. The only truly safe option is still to leave withdrawal off.

How your script uses the key to place orders

To understand the risk a key carries, you first need to be clear about who uses it, and how.

Your strategy runs on your own computer or on a server. It doesn't “log in” to the exchange; it sends requests to an HTTP API. Every request carries your apiKey plus a signature computed with your secret key. The platform verifies the signature, concludes “this came from whoever holds that key,” and does what it's told. Nowhere in that loop is there a human confirmation, an SMS code or a second pop-up — the key is your identity.

Very few people write the signing code themselves. Most use an off-the-shelf library (a unified-interface library like the one above is the most common kind), put the key into a config, and let the library handle the rest. That's convenient, but it also means your key sits in plain text somewhere — in a config file, an environment variable or your code — and that is exactly where leaks begin.

What a leaked key can and can't be used for

Suppose your key has only Read and Trade enabled, withdrawal is off, and the key has now ended up in someone else's hands.

There are really only two things they can't do: withdraw coins to an on-chain address (that needs the separate withdrawal permission), and log in to your account on the web (that needs your login credentials). So your first assumption doesn't have to be “the coins are already gone.”

But the “can't do” list is shorter than a lot of people think. OKX's API documentation describes the Trade permission as able to “place and cancel orders, funding transfer, make settings.” In other words, transfers between the funding and trading accounts, transfers between the main account and sub-accounts, and some account settings are all possible with Trade alone. The idea that “Trade is on but withdrawal is off, so they can't even move funds around” doesn't hold. The money still can't leave your set of accounts, but it can be moved between them — and that is exactly the step before an attacker pools funds in one tradable account and uses them for fills that benefit them.

What they can do is the genuinely nasty part:

• Dump or pump using your balance. The attacker places their own orders in advance on a very illiquid pair, then hits those orders with market orders from your account. Your money fills at a terrible price and the difference lands in their pocket. The funds never left your account, but the value has already been transferred. It's a play many people never think of, and it's the biggest hole in the claim that “Trade-only is safe.”
• Churn trades to burn fees. Nothing clever required: keep crossing trades back and forth and your balance gets eaten away bit by bit.
• Mess with the positions you're running. Cancel your open orders, close your positions, or open a large position in the opposite direction on your futures account.
• Transfer between your own accounts. Between the funding and trading accounts, between the main account and sub-accounts. The coins stay in your name, but the sub-account split you set up to ring-fence risk can be wiped out with a single transfer.
• Change some account settings. For example, settings the API can change, such as account mode and leverage; check the platform's documentation for exactly which ones.

Put simply: without withdrawal permission, your assets won't be moved on-chain, but they can be traded into less money, and transferred into an account you weren't expecting. That's why least privilege has to be paired with the lock in the next section.

IP whitelist: the best-value lock

If this article could leave you with only one recommendation, it would be this: bind your key to an IP whitelist.

The logic is clean: the key only works for requests that come from the IPs you specified. Even if it leaks, it's useless — calls from the attacker's own machine are simply rejected. This lock doesn't depend on you remembering to change passwords or spotting something odd in time. It's structural, not a matter of personal discipline.

It's cheap, too. Run your script on a server with a fixed IP (even the cheapest kind), configure it once, and you're done. If your script runs on a home connection whose IP changes, you'll find this a hassle — which is actually one more reason to move your strategy onto a fixed-IP machine, beyond keeping it running when the power goes out.

There's also a rule that's easy to overlook: per OKX's official documentation, API keys that are not linked to an IP address and have trade or withdraw permissions expire after 14 days of inactivity. So a key with no IP binding isn't just riskier; it can also stop working on its own one day, leaving your script unable to connect for no obvious reason. On top of that, each key can be bound to up to 20 IP addresses (IPv4, IPv6 and network segments are supported), so leaving some headroom for an outbound IP that might change isn't hard.

But be clear about what it doesn't stop. A whitelist protects against “someone using your key from somewhere else”; it doesn't protect against “your own machine being compromised.” Once that machine is under someone else's control, requests go out from a whitelisted IP and the lock is worthless. So it stacks with least privilege; it doesn't replace it.

Where keys usually leak from

Keys are rarely “hacked.” Most of the time they walk out the door on their own. Roughly from most to least common:

• Committed to Git. Hard-coded in the source and pushed with a casual commit. Even if the repo is private, and even if you later deleted that line, it's still in the history — and there are people who scan public repositories specifically for strings like these.
• Caught in a screenshot. You post a terminal screenshot asking for help, or record a screen demo, and the config line happens to be in frame. A key is a long random string that the eye skims straight past, but it's right there.
• Pasted into a group chat for help. You copy the error message together with the config into a group of several hundred people, and you have no real idea who they all are.
• An unvetted “strategy script.” This is the category with the worst consequences: someone hands you a “can't-lose bot” and asks you to paste your apiKey into it. Which server that script connects to, and where it sends your key, you have no way of knowing. Any third-party program that asks for your API key should be treated, by default, as something that will take it.
• Logs and error output. While debugging you print the entire request object, and the key ends up in a log file. Logs are often less tightly protected than code, and may even get uploaded to some logging service.

Putting least privilege into practice

“Least privilege” isn't a slogan. Broken down, it's a handful of concrete habits:

• One key, one purpose. Dashboards and stats scripts get a Read-only key; the strategy that places orders gets a Trade key. Keep the two separate. If the dashboard key leaks, all you lose is information — and when something goes wrong you can tell straight away which path it leaked through.
• One key per strategy. If you run several strategies at once, don't share a key between them. When something goes wrong you shut down one key and the others aren't affected.
• Rotate regularly; delete what you don't use. Every key is an exposure. Delete test keys as soon as you're done with them — an account cluttered with keys whose purpose you've long forgotten is the most common weak spot.
• Keep keys out of your code. Put them in environment variables or a local config file that doesn't get synced, and add that config file to .gitignore.
• Keep bot money apart from your main holdings. If the platform supports sub-accounts, put your quant capital in a sub-account of its own and leave your main holdings out of it. If the strategy misbehaves or the key is compromised, the damage is capped. One caveat: this isolation only holds if you use the sub-account's own key. A main-account key with Trade permission can transfer between the main account and sub-accounts, so running a strategy on it opens the isolation right back up.

If a key leaks: what to do, in order

1. Delete the key first; look for the cause later. Log in and delete that key outright — don't edit its permissions, delete it. Cutting off the attacker's access is more urgent than working out what happened; the cause can be investigated afterwards.
2. Stop any programs that are running. Otherwise your strategy will keep throwing errors once the key stops working, and may trigger some odd retry logic.
3. Check open orders and positions. Cancel every order you didn't place yourself and look for positions someone else opened, especially on the futures side.
4. Go through your recent trade history. Look for fills at prices well off the market and orders you never placed. This step tells you how big the loss really is.
5. Check transfer records and sub-accounts. Trade permission can transfer funds by itself, so looking at orders isn't enough: go through the transfer history between the funding and trading accounts and between the main account and sub-accounts, then confirm one by one that each sub-account's balance adds up.
6. Check whether account settings were changed. Go through settings that can be changed via the API, such as account mode and leverage, and confirm they're the ones you set.
7. Change your account credentials. Reset your password and two-factor authentication together, because you can't yet be sure the key is the only thing that leaked.
8. Create a new key, this time with minimal permissions and an IP whitelist. Then go back and trace the leak path: code, screenshots, logs, any scripts you installed — one at a time.

The whole point of this order is step one. Many people's first reaction to something odd is to take screenshots, ask around and try to figure out what's going on — and all that time the attacker is still using the key. Shut the door first, then work out how it was opened.

FAQ

Once you've done all of this, the risk around your API keys goes from “down to luck” to “capped.” If you'd like to tick through it item by item, use the API security checklist; if you haven't got as far as writing scripts yet, start with what quant trading actually is. One more reminder: however well you guard your keys, it won't help if the strategy itself loses money — before real money goes in, it's worth going over how to backtest a strategy.