WEEX API Key Security: What a Leaked Key Can Still Do to You

API key security on WEEX is easier than on many exchanges for one structural reason: no API scope can withdraw funds. But "cannot withdraw" is not the same as "cannot cost you money". A leaked key with Spot or Futures/Contract trade scope can be used to trade your balance into an attacker's pocket without a single withdrawal, and that attack pattern has emptied accounts on exchanges across the industry. This article explains how the attack works, where keys actually leak in practice, and the five controls, led by IP binding, that make a leaked WEEX key close to worthless. It ends with a revoke-and-rebuild procedure for the day you suspect a compromise.

What a leaked WEEX API key can and cannot do

Start with the boundary. WEEX's API documentation for spot and for futures lists two permission types: Read Only, the default for every new key, and Trade, split into a Spot scope and a Futures/Contract scope. There is no withdrawal scope and no transfer-out scope. Getting coins off the exchange still requires the web or app flow, your 2FA, and whatever withdrawal address controls you have enabled.

So a leaked read-only key exposes information: balances, open orders, trade history, position sizes. That is a privacy problem and a targeting problem, since an attacker now knows exactly how much you hold and how you trade, but it is not a direct loss.

A leaked trade-scoped key is different. The attacker can place and cancel orders as you. On a liquid pair that mostly lets them lose your money at random, which is bad but not lucrative for them. The real damage comes from the counter-trading pattern described below, and from leverage: with a Futures/Contract key, an attacker can open the largest position your margin allows and let the market do the rest.

The counter-trading attack: How leaked keys are monetised

The pattern has been documented repeatedly across exchanges, and it works without withdrawals.

The attacker holds a position on a thinly traded pair, or on the illiquid side of a futures order book. Using your leaked key, they place market or aggressive limit orders from your account that push the price into their resting orders. You buy their inventory at inflated prices, or sell into their bids at depressed prices. Your balance converts into their profit inside the exchange's own matching engine. Repeated over a few minutes on several pairs, the process can drain most of an account, and because every order was legitimately signed by your key, it looks like your trading.

Three features of WEEX's setup change the economics of this attack. IP binding, if you used it, means the attacker's requests are rejected outright. One trade scope per key means a stolen spot key cannot touch your futures margin, and vice versa. And the ORDERS rate limit, which is applied per account rather than per IP, caps how fast anyone, including an attacker, can fire orders from your account; exceeding it returns HTTP 429 and a 10-second ban. None of these substitutes for keeping the key secret, but together they turn a catastrophic leak into a contained one.

Where API keys actually leak

Most compromised keys are not stolen by breaking encryption. They are copied from somewhere the owner left them.

• Source control. A SecretKey pasted into a config file and pushed to a public repository is harvested by automated scanners within minutes. Private repositories leak too, through forks, CI logs, and ex-collaborators.
• Screenshots and screen shares. The API Management page shows the SecretKey once. A screenshot taken "to save it" and synced to a cloud photo library is a common origin story.
• Third-party bot and portfolio platforms. When you paste a key into a hosted service, its security becomes your security. A breach at the platform exposes every key it stored, and a trade-scoped key with no IP binding is immediately usable from the attacker's infrastructure.
• Shared or cheap VPS hosts. Keys in environment variables or plain-text files on a server with weak SSH hygiene, reused passwords, or an exposed dashboard.
• Logs. A debugging line that prints request headers will write ACCESS-KEY and, in badly written clients, the raw secret into log files that are then shipped to a log aggregator.
• Chat and ticket systems. Keys pasted into a support chat or a team channel to "check if it works".

The pattern across all six is the same: the key was never attacked; it was exposed. Which is why the controls that matter are about limiting what an exposed key can do, not about stronger encryption of the key at rest.

The five controls that make a leaked key close to worthless

Ranked by how much loss they prevent per minute of effort.

1. IP binding. Bind every trade-scoped key to the static IP of the machine that uses it. A leaked key that only works from your VPS is a key the attacker cannot use. WEEX's documentation flags unrestricted keys as a security risk for exactly this reason. If your program runs from a dynamic home IP, either move it to a VPS or keep the key read-only.
2. Least scope. Read Only by default; one trade scope only when a program provably needs it. Never enable Spot and Futures/Contract on the same key. Most of the tools people connect (trackers, tax exports, alerting) need read-only access and nothing more.
3. One key per program, per machine. WEEX allows 10 key groups. Spend them on isolation so that a compromise of one tool costs you one key, not all of them, and so that order history tells you which program placed what.
4. Secrets management. Keep the SecretKey and Passphrase in an OS keychain, a secrets manager, or at minimum an environment file excluded from version control. Never in code, never in screenshots, never in chat. Remember that the passphrase is unrecoverable: losing it forces a new key, so store it with the same care.
5. Rotation on a calendar. Create a replacement key, switch the program over, confirm it works, then delete the old key. Quarterly is a reasonable cadence for trade-scoped keys, and immediately for any key that has touched a third-party platform you have stopped using. Allow for the roughly 15-minute propagation delay WEEX notes for new or modified keys before you cut over.

Account-level protections sit underneath all of this. Authenticator-app 2FA rather than SMS, an anti-phishing code on emails, and withdrawal address restrictions all reduce the chance that a key leak escalates into a full account takeover. WEEX's Learn guide on securing your crypto assets walks through those settings.

Signs your WEEX API key has been compromised

Because a leaked trade key produces orders that look like yours, detection depends on noticing what you did not do.

• Fills on pairs you have never traded, especially low-liquidity ones.
• A burst of small orders in a short window, or repeated HTTP 429 responses in your own program's logs when it should be well under its limit; someone else may be consuming your per-account order budget.
• Positions opened at maximum leverage on a futures key.
• Balance changes that your own program's records cannot account for.
• Authentication failures from your bound IP right after a period when the key worked; this can indicate a key was modified.

A read-only monitoring key that polls open orders and recent fills every minute and alerts on anything unexpected is a cheap early-warning system, and it uses a scope that cannot itself be abused.

Suspected leak: The revoke-and-rebuild procedure

Do this in order, and do not stop halfway.

1. Delete the suspect key group in API Management immediately. Do not "just remove trade scope" and investigate later; deletion is instant and complete.
2. Cancel all open orders and review positions on web or app. Close anything you did not open.
3. Check recent order history for fills you do not recognise, note the pairs and times, and contact WEEX support with the details.
4. Change your account password and re-enrol 2FA if there is any chance the leak came from a device compromise rather than a file exposure.
5. Find the leak source before issuing a new key. If it was a repository, purge the history; if a third-party platform, disconnect it; if a server, rebuild it.
6. Create a new key with the correct scope, IP binding, and a fresh passphrase, then update the program.
7. Review your other keys. A leak in one place often means the same bad habit exposed others.

Practical risk: What experienced operators watch

The keys that get people hurt are rarely the ones they think about. They are the key created in 2024 for a bot that was abandoned, still holding Futures/Contract scope, never bound to an IP, sitting in a config file on a VPS that was cancelled but whose disk image persists somewhere. Audit your API Management page now: for each key, ask what program uses it, whether it still needs trade scope, whether it is IP-bound, and how old it is. Delete anything you cannot answer for. That single exercise does more for your API key security than any amount of encryption advice.

FAQ

1. Can a leaked WEEX API key withdraw my funds?

No. As of September 2026, WEEX API permissions are limited to Read Only and Trade (Spot or Futures/Contract). Withdrawals require the web or app flow with 2FA.

2. Then why does API key security matter on WEEX?

A trade-scoped key can be used to trade your balance into an attacker's positions through counter-trading on thin pairs, or to open maximum-leverage futures positions. Loss happens inside the exchange without any withdrawal.

3. Is IP binding enough on its own?

It is the single most effective control, because a key that only works from your server cannot be used by anyone else. Combine it with least scope and rotation; do not rely on it alone.

4. How often should I rotate WEEX API keys?

Quarterly for trade-scoped keys is a reasonable default, and immediately after disconnecting any third-party platform. Create the new key, switch over, then delete the old one.

5. I lost my passphrase. Is the key compromised?

Not necessarily, but it is unusable, and WEEX cannot recover it. Delete the key group and issue a new one.

6. Can WEEX support reverse trades made with a leaked key?

Orders signed with a valid key are executed as legitimate trades and are not reversible. Report the incident to support for investigation, but assume losses are final and act on prevention.

Risk Warning

Cryptocurrency trading carries a high risk of loss, including total loss of funds, and leveraged futures positions can be liquidated in minutes during volatile markets. API access introduces counterparty and operational risks beyond market risk: a leaked or over-scoped key, a compromised third-party platform, or a bug in your own program can execute trades you did not intend, and those trades cannot be reversed. Binding keys to an IP, granting the minimum scope, isolating keys per program, and rotating them regularly reduces but does not eliminate this risk. This article describes WEEX API features as of September 2026 and is not investment advice.