Docs·Web App·Security

API key permissions — the safety net

Why the trade-only + IP-whitelisted API key model means a leaked Binance key cannot withdraw, cannot transfer, and cannot be used from any other machine. The last layer of defence — designed to make the worst case still survivable.

If you've read the previous three pages — security overview, what a PWA cannot do, verify the build — you have three layers of defence: the browser sandbox, the strict CSP, the verifiable build. This page is layer four — the one that assumes the previous three failed and asks: if a malicious actor somehow got your API key, what could they actually do?

The short answer, if you follow the key-generation flow we document, is almost nothing. Trade your futures balance into unfavourable prices, yes. Drain your wallet, no. Transfer to another account, no. Use the key from any machine other than ours, no.

This page explains why, with concrete steps to lock down each lever.

1. The withdraw bit must be OFF

Every exchange's API key has independent permission flags. On Binance the relevant ones for our integration are:

PermissionWhat it lets the key doWe require
Enable ReadingRead balances, orders, fills, positions.ON
Enable Spot & Margin TradingPlace spot orders.Off (unless you also trade spot through us, currently read-only).
Enable FuturesPlace USDⓈ-M / coin-M futures orders.ON (this is the engine of Auto Trade).
Permits Universal TransferMove funds between Binance sub-accounts.OFF — must be off.
Enable WithdrawalsSend funds to an external address.OFF — must be off.
Enable Symbol White ListRestrict the key to specific symbols.Optional; reduces attack surface further.

When you paste a key on our API Connect page we run the Binance GET /sapi/v1/account/apiRestrictions endpoint to check the flags before storing anything. If enableWithdrawals or permitsUniversalTransfer come back true, the validation outcome is:

❌ Withdrawal enabled — please disable

…and we do not persist the key. You go back to Binance, untick the box, save, and re-paste.

This is not a soft recommendation. It is a refusal-to-accept. A trader who somehow forces a withdrawal-enabled key onto our platform (by editing the request, say) would find that our backend rejects every operation with the key until they regenerate it the right way.

2. Why the withdraw bit bounds the worst case

Consider every "what if" people worry about:

ScenarioWhat attacker can do with trade-only key
Bundle compromised, key + secret exfiltrated.Place orders on your account in unfavourable directions. Cannot withdraw. Cannot transfer to attacker's account.
Our database leaks.Same as above — leaked key + secret, no withdrawal. (Note our DB stores keys encrypted; see §5.)
Insider attack at our company.Same as above. We don't have a "withdraw" lever anywhere — the lever doesn't exist on a trade-only key.
Browser extension malware on your machine reads our login session.Attacker can log in as you; from inside the dashboard they can still only place trades. The withdraw button on Binance is on Binance's site, behind Binance's 2FA.
Phishing site pretending to be us, asks for key + secret.Same — trade-only key, no withdraw. (Plus: a phishing site cannot bypass the IP whitelist, see §3.)

The attacker's best move with a trade-only key is to trade your balance into a losing position — buy at the top of an illiquid alt and sell at the bottom, say. That's still bad: you can lose money. But it's bounded by your balance, and it leaves an obvious audit trail on Binance's side (so you can dispute or report to Binance support).

The attacker cannot turn your futures balance into a transfer to their wallet. That is the lever you're afraid of. Removing the withdraw bit removes the lever.

3. IP whitelist — even a leaked key cannot be used elsewhere

The second lock: bind the key to a specific set of IPs. Binance (and Bybit, OKX, Bitget, Kucoin) all support this. When the flag is set, Binance refuses any signed request that arrives from an IP not on the list.

We publish our server IPs on the API Connect → IP whitelist page. Paste them into Binance's whitelist field, tick the box, save.

Now even if your key + secret leak in plaintext to a Telegram channel of 10,000 traders:

  • An attacker pasting them into their own bot from their home IP → Binance refuses every request. "IP not in whitelist."
  • An attacker using a botnet to spray from 1,000 different IPs → none of those IPs are on the whitelist. Every request refused.
  • An attacker hosting on Binance Cloud, AWS, GCP → same — not on the whitelist.

The only way an attacker can use a whitelisted key is if they break into one of our servers and make the request from there. Our server IPs are themselves locked down (firewall, no SSH access for unprivileged users, audit logs) — but if they fall, the worst case is still trade-only orders (no withdrawal). Two locks, both must fail.

4. Concrete setup walkthrough

Five minutes, one-time setup:

  1. Generate the key on Binance. Top-right → Account → API Management → Create API → System generated. Name it mrD-Indicators. Pass 2FA. Copy the API key and the secret immediately — the secret is shown once.
  2. Set the permissions. Click Edit restrictions on the new row.
    • ☑ Enable Reading
    • ☐ Enable Spot & Margin Trading
    • ☑ Enable Futures
    • ☐ Permits Universal Transfer
    • ☐ Enable Withdrawals ← the important one
    • Save. Pass 2FA.
  3. Add IP whitelist. Same Edit page → "Restrict access to trusted IPs only" → paste the IPs from our IP whitelist page → save → pass 2FA.
  4. Paste on our side. Open API Connect → + Connect → Binance Futures → paste key + secret → label as "Main" → Validate.
  5. Watch the validation outcome. A successful flow shows ✅ Connected. Any of the failure outcomes are tracked in the API Connect overview — usually a missed permission box.

That's it. From this moment forward, any leak of the key+secret is bounded by what we described in §2 and §3.

5. What we store, encrypted at rest

For completeness, the data we hold on our backend per connected key:

  • API key — encrypted at rest with AES-256-GCM, key rotation per environment.
  • API secret — same, encrypted at rest, never sent back to the browser.
  • The IP-whitelist value you set (not the secret behind it — we just remember which IPs you whitelisted for our own audit).
  • The exchange + label you chose.

We do not store:

  • Your exchange password.
  • Your 2FA codes (not even hashed — we never see them).
  • Your withdraw whitelist (the list of addresses Binance lets you send to).
  • Your hardware-wallet seed phrase. We have no flow anywhere in the app that asks for one. If anyone claiming to be us asks for a seed, it is a scam. Forward the message to support and we will warn the rest of the user base.

Every secret is encrypted with a key held only by our trade-execution servers — the front-end and our public dashboards have no access path. Even our own engineers cannot read the decrypted secret without going through a break-glass procedure that is logged and alerts the whole security team.

6. Rotation

Keys do not expire on Binance unless you rotate them. Good hygiene:

  • Rotate every 6 months. Sooner if you suspect any of your devices is compromised.
  • The rotation flow is non-disruptive: create a new key with the same permissions, paste it on our side as a second card (autotrade continues on the old key), verify the new card is ✅ Connected, then delete the old card on our side and delete the old key on Binance. Total downtime: zero.

If you ever suspect a leak:

  1. Delete the key on Binance immediately. That kills it everywhere, including for us.
  2. Re-create with the same permissions.
  3. Paste the new one on our API Connect page.
  4. Inspect Binance's API audit log (API Management → click the key → Recent uses) for any unexpected source IP. With the whitelist in place, you should see only our IPs.

7. Reference