API Key Security Best Practices

Key Takeaways

An exchange API key is a separate credential from your login password, with its own permission scope and its own storage location — usually inside whatever third-party tool it was created for. Because of that, the security of an API key depends on decisions made at the moment it's created and on the security practices of whatever application holds onto it afterward, not on how strong the exchange account's password happens to be.

Direct answer: Grant the minimum permission scope an application actually needs — read-only whenever possible, trade-enabled only when a tool genuinely places orders, and withdrawal permission almost never — restrict the key to a whitelisted IP address when the connecting application supports one, only connect keys to reputable and well-reviewed third-party tools, and periodically review and revoke keys tied to tools no longer in use.

• A leaked read-only key can expose balances and trade history but cannot move funds or place orders.
• A leaked withdrawal-enabled key can drain an account directly, with no further action required from the account holder.
• IP whitelisting makes a stolen key largely useless to an attacker connecting from an unapproved location, even with the correct key and secret in hand.
• API keys are commonly compromised through the third-party tool's own storage practices, not through the exchange itself being breached.
• A strong exchange login password provides zero protection to an API key that's already been issued and handed to another application.
• An unused API key left active on an exchange account is a standing liability with no offsetting benefit.

What an Exchange API Key Is, and Why Traders Create One

An exchange API key is a programmatic credential — typically a public "key" string paired with a private "secret" string — that lets an external application authenticate directly with an exchange's trading infrastructure and act on an account without a human logging in for each action. A piece of software presents the key and secret with each request, and the exchange treats that request as authorized on the account holder's behalf, within whatever limits were set when the key was created.

Traders create API keys to let some outside tool do something continuously or automatically that would otherwise require constant manual attention. A trading bot that executes a strategy around the clock needs to place orders without a person present to click "confirm" every time. A portfolio tracker aggregating balances across several exchanges needs to pull account data on a schedule rather than asking the user to log into each one separately. A tax-reporting tool needs historical trade data; a rebalancing script needs to check allocations and occasionally adjust them. In every case, the API key is the mechanism by which a program, rather than a person, gets to interact with a real financial account.

This convenience is exactly why API keys carry real risk. A login password protected by two-factor authentication is something only the account holder is meant to type in, at the moment they're actively using the exchange. An API key, by contrast, is deliberately handed off to a third party and left there indefinitely so it can keep working without further involvement. That handoff is the entire point of the credential, but it also means the key's safety depends on decisions made once, at setup, and on the ongoing security practices of whatever holds it — not on anything the account holder does in the moment.

Most exchanges make API keys straightforward to create: a settings page generates a key and secret pair, presents the secret exactly once (since it's typically not retrievable again after that point), and offers a set of permission toggles and optional restrictions to configure before the key becomes active. Those toggles are the single most consequential part of the setup process, and they're the subject of the next section.

Permission Scoping: Read-Only, Trade-Enabled, and Withdrawal-Enabled

Nearly every major exchange lets an account holder restrict exactly what a given API key is allowed to do, independent of what the account itself is capable of. This scoping typically falls into three tiers, each strictly broader than the last.

Read-only

A read-only key can view information — balances, positions, order history — but cannot place a trade, cancel an order, or move funds anywhere. This is the correct scope for the largest category of third-party tools: portfolio trackers, tax software, and any application whose entire job is displaying or analyzing data rather than acting on the account. If a read-only key leaks, an attacker can see what's in the account, which is not nothing from a privacy standpoint, but they cannot touch a single unit of it.

Trade-enabled

A trade-enabled key can place and cancel orders — buying, selling, opening and closing positions — in addition to everything a read-only key can do, but it still cannot withdraw funds to an outside address. This is the correct scope for trading bots and automated strategies that genuinely need to execute trades on the account holder's behalf. A leaked trade-enabled key is worse than a leaked read-only one, since an attacker could place damaging trades or run up losses through reckless orders, but the funds remain inside the exchange account and cannot be directly extracted through the key alone.

Withdrawal-enabled

A withdrawal-enabled key can move funds out of the account to an external address, on top of everything the trade-enabled tier allows. This is the highest-consequence permission an API key can carry, because it's the one that turns a leaked credential into an immediate, direct, and often irreversible loss of funds. There is a real gap between what most third-party tools claim they need withdrawal permission for and what they actually need functionally — a trading bot places trades and typically has no need to send funds anywhere, and a portfolio tracker only ever needs to read data. Withdrawal permission should be treated as almost never appropriate to grant to a third-party tool, reserved for the narrow cases where an application's entire stated function is moving funds on a defined schedule, and even then only after independently verifying that function is real.

The practical rule that follows: match the permission scope to the narrowest tier the tool's actual function requires, not the broadest tier the exchange happens to offer. A trading bot that places orders needs trade-enabled access, not withdrawal-enabled access "just in case." If a tool's stated purpose doesn't obviously require a given permission tier, that's a signal to leave it switched off, not a gap to fill defensively.

IP Whitelisting: A Second Layer Beyond Permission Scope

Permission scoping controls what a key can do; IP whitelisting controls where it can be used from. Many exchanges let an account holder restrict a given API key so that requests are only accepted when they originate from a specific IP address, or a small list of pre-approved addresses, rather than from any location on the internet. When this restriction is active, the exchange checks the source of every incoming request against the whitelist first, and rejects requests from any address not on the approved list, regardless of whether the key and secret presented are otherwise valid.

This matters because it changes what a stolen key is actually worth to an attacker. Without IP whitelisting, a leaked key and secret are immediately usable from anywhere — an attacker who obtains the credential, whether through a data breach, malware, or a compromised third-party service, can start issuing requests from their own infrastructure the moment they have it. With IP whitelisting active, that same leaked credential is largely inert unless the attacker also happens to be operating from one of the whitelisted addresses, a meaningfully higher bar than simply obtaining a key and secret. IP whitelisting doesn't prevent a key from being stolen, but it substantially narrows what stealing it accomplishes.

The practical limitation is that IP whitelisting only works cleanly when the connecting application runs from a stable, known IP address — a bot on a fixed server or cloud instance is a natural fit. A tool running locally on a home connection with a dynamic IP is a worse fit, since the whitelist would need constant updating, defeating its practical value. Use IP whitelisting whenever the connecting application supports a stable address — many reputable trading bot services run from fixed server infrastructure specifically so users can enable this — and treat its absence as a real, if sometimes unavoidable, gap in the key's defenses.

The Risk of Over-Broad Key Storage

Permission scoping and IP whitelisting are both exchange-side controls — settings configured once, at the exchange, when the key is created. Neither one has any bearing on what happens to the key after it leaves the exchange's systems and lands inside whatever third-party application it was issued to. That's where a large share of real-world API key compromises actually originate, and it's a risk that exchange-side settings cannot address at all.

Once a key and secret are handed to a third-party tool, that tool becomes responsible for storing them securely — typically encrypted at rest, transmitted only over secure connections, and never exposed in logs or debugging output. A well-run service treats this as core to its own security posture. A poorly run one, or a deliberately malicious one, might store keys in plain text, log full request payloads including the secret, or simply never think through the storage question at all. From the account holder's perspective, none of this is visible — a tool's interface can look identical whether the keys behind it are encrypted carefully or sitting in a plain text file on a poorly secured server.

Beyond the third-party tool's own infrastructure, a handful of common human errors account for a large share of leaked API keys independent of any tool at all: pasting a key and secret into a configuration file that ends up in a public code repository, where automated scanners actively search for exposed credentials within minutes of a commit; including a key or secret visible in a screenshot shared for troubleshooting help; or storing keys in an unencrypted note-taking app or spreadsheet synced to cloud storage. None of these mistakes involve the exchange or the third-party tool being breached at all — the credential simply ends up somewhere it shouldn't, through the same carelessness that exposes any other sensitive string of text.

The upshot: the third-party tool's own security practices matter just as much as the permission scope chosen at the exchange, and arguably more, since a narrow scope limits the damage a leak can do but does nothing to prevent the leak from happening if the tool holding the key is careless with it. Vetting a tool's reputation and storage practices before connecting a key isn't a separate, optional step from configuring permissions — it's the other half of the same decision.

Worked Example: A Withdrawal-Enabled Key Handed to a Shady Bot

Hypothetical example — for education only.

Assume a reader comes across a "trading bot" service advertised in a crypto Telegram group, promising an automated strategy that consistently outperforms simply holding. The service has a polished-looking website, a handful of enthusiastic testimonials, and a setup guide that walks new users through creating an exchange API key. The guide instructs users to enable read, trade, and withdrawal permissions on the key "so the bot can fully manage the account and automatically move profits to a separate savings wallet," and doesn't mention IP whitelisting at all. Reassured by the testimonials, the reader follows the instructions exactly: they create a new key, switch on all three permission tiers including withdrawal, skip the IP whitelist field since the guide didn't ask for it, and paste the key and secret into the bot service's setup form.

For a few weeks, everything appears to work as advertised. The bot places a modest number of trades and the account balance moves in ways that look plausible, giving the reader no reason to suspect anything is wrong. Behind the scenes, though, the bot service's own backend — the servers where every customer's API keys, the reader's fully permissioned one included, are stored — has security gaps the operators never fixed: an exposed database, weak internal access controls, keys stored without meaningful encryption. An attacker with no connection to the reader personally finds and exploits that gap, gaining access to the service's entire database of stored customer credentials.

Because the reader's key was withdrawal-enabled with no IP whitelist restricting where it could be used from, the attacker doesn't need to touch the bot service's interface, guess a password, or bypass two-factor authentication on the reader's exchange account at all, since API keys are a separate credential from all of that. They simply issue withdrawal requests directly against the exchange's API using the stolen key and secret, from their own infrastructure, and the exchange has no basis to reject those requests — the credential is valid, and nothing about it says where a legitimate request should originate. Funds move out to an address the attacker controls within minutes, with no login attempt, password reset, or two-factor prompt anywhere in the sequence. The reader discovers the loss only when they next check their balance and find an exchange withdrawal entry they never authorized.

Two decisions made weeks earlier are what turned an unvetted bot's own security failure into a direct loss of funds: granting withdrawal permission to a tool that only needed trade access to do its stated job, and skipping IP whitelisting entirely. Either one alone would likely have contained the damage — a trade-only key would have let the attacker place disruptive trades but not extract funds directly, and an IP-whitelisted key would have made the stolen credential largely useless from the attacker's own infrastructure. Both together closed off nearly every path the attacker actually needed.

Practical Defenses

Protecting an exchange account that's connected to third-party tools comes down to controlling three separate things: what a key is allowed to do, where it can be used from, and who's holding onto it.

Use the minimum necessary permission scope for the tool's actual function

Before enabling any permission tier, ask specifically what the tool needs to do its stated job, not what it's technically capable of asking for. A portfolio tracker or tax tool needs read-only access and nothing more. A trading bot needs trade-enabled access, but that doesn't extend to withdrawal access unless the tool's entire stated purpose is moving funds on a defined schedule — and even then, that claim deserves independent verification first. Default to the narrowest tier and only widen it when a verified functional need requires it.

Enable IP whitelisting wherever the connecting application supports it

If a trading bot or automated tool runs from a fixed server or cloud instance with a stable IP address, restrict the key to that address specifically. This single setting substantially reduces what a leaked key is worth to an attacker operating from anywhere else, and reputable services running persistent trading infrastructure are generally well positioned to support it.

Only connect API keys to reputable, well-reviewed third-party tools

Before handing a key to any bot, tracker, or automation service, look for a real track record: how long the service has operated, whether independent users have reviewed it outside of testimonials the service controls itself, whether it publishes anything about how it stores customer credentials, and whether its requested permission scope actually matches what it claims to do. A service that surfaced recently through a chat-group ad, has no verifiable reputation, or asks for more permission than its stated function requires is a meaningfully higher-risk place to send a credential capable of touching real funds.

Periodically review and revoke unused API keys

Every active API key is a live credential capable of doing whatever it was scoped to do, whether or not the tool it was created for is still in use. Reviewing the full list of active keys on each connected exchange every few months, and revoking any tied to a tool no longer used, removes credentials that serve no ongoing purpose but remain a permanent point of exposure until deleted.

Common Mistakes

Two mistakes account for most of the avoidable losses tied to exchange API keys, and both are decisions made once, at setup or shortly after, rather than ongoing vigilance failures.

The first is granting withdrawal permission to a trading bot or automation tool "just in case" it turns out to be needed later, or because a setup guide asked for it without the user questioning whether the tool's actual function required it. Withdrawal permission is the single tier that turns a leaked key into a direct loss of funds, and the overwhelming majority of trading and tracking tools never legitimately need it. Granting it defensively is choosing the worst-case outcome of a future leak for no functional benefit in the present.

The second is never reviewing or revoking API keys tied to tools no longer in use. A bot subscription that lapsed months ago or a portfolio tracker abandoned for a different one can leave a fully functional API key sitting active indefinitely, with no one checking on it and no reason for it to still exist except that revoking it was never anyone's specific task. An old, forgotten key is exactly as dangerous as a new one if it leaks; forgetting about it doesn't reduce the risk, it just removes anyone's ability to notice it.

Misconceptions Versus Reality

Risks, Limitations, and Exceptions

• Permission scoping and IP whitelisting are configured differently, and named differently, across exchanges; confirm the exact behavior of a given exchange's settings rather than assuming they match another exchange's terminology.
• Some legitimate automation genuinely requires withdrawal permission, such as a service built to sweep funds to cold storage on a schedule; in those narrow cases, independently verify the service's function and reputation before granting that tier.
• IP whitelisting is impractical for applications without a stable IP address, such as tools run from a home connection or mobile device, which leaves that layer unavailable regardless of intent.
• Reviewing and revoking unused keys requires remembering which tools are still active across every connected exchange, which grows harder to track as the number of connected tools grows.
• Even a correctly scoped, IP-whitelisted key connected to a reputable tool is not risk-free; it reduces the scope of damage from a leak, but no configuration eliminates risk entirely for a credential handed to an outside party.
• This page focuses on exchange API key permissions and storage; the related discipline of reviewing on-chain token approvals granted to decentralized applications is covered separately in the token allowance checker tools guide, since the underlying credential and revocation mechanics differ.

Practical Implementation Checklist

1. Before creating any API key, identify the minimum permission tier the connecting tool's actual function requires — read-only for trackers and tax tools, trade-enabled for bots that place orders, and withdrawal-enabled only for a specifically verified, legitimate need.
2. Enable IP whitelisting whenever the connecting application runs from a stable IP address, restricting the key to that address specifically.
3. Research a third-party tool's track record, independent reviews, and published security or storage practices before connecting any API key to it.
4. Never paste an API key or secret into a plain text file, a code repository, a screenshot, or an unencrypted note-taking or spreadsheet app.
5. Review the full list of active API keys on every connected exchange every few months.
6. Revoke any API key tied to a tool that's no longer in active use, immediately rather than "eventually."
7. If a key is ever suspected of being compromised, revoke it on the exchange immediately, then create a new one with the same minimum-necessary permission scope rather than reusing the old key's settings by default.

Tool Opportunity

A dedicated Swoopr tool should help readers see, at a glance, whether their currently active API keys across connected exchanges are over-permissioned relative to what they're actually being used for.

Recommended inputs: a manually entered summary of each active API key's exchange, permission tier (read-only, trade-enabled, or withdrawal-enabled), whether IP whitelisting is active, and the tool or purpose the key was created for — never the key or secret itself.

Expected outputs: a flagged list highlighting any withdrawal-enabled key, any key without IP whitelisting where the connecting tool plausibly supports it, and any key whose stated purpose no longer matches an active use, alongside a plain-language recommendation for each flagged entry.

Validation requirements: never request or accept an actual API key or secret value as input, run all comparisons entirely client-side so nothing about a user's exchange setup leaves their device, and clearly label the output as a self-audit aid rather than a live security scan of any exchange account.

Sources

• Coinbase Help Center — official documentation on creating and managing API keys, including available permission scopes and IP allowlisting options for programmatic account access.
• Kraken Support — guidance on API key permission tiers and the exchange's recommendations for restricting key scope and access when connecting third-party applications.
• OWASP Foundation — the OWASP API Security Project's guidance on credential exposure, excessive permission grants, and secure secret storage, applicable to any service issuing and storing API-style credentials.

Conclusion

An exchange API key is a separate, independently risky credential from an account's login password, and its safety comes down to three decisions: how narrowly its permissions are scoped, whether it's restricted to a known IP address, and how carefully the third-party tool holding it treats that responsibility. Withdrawal permission in particular should be reserved for the rare, verified case where it's genuinely required, since it's the single setting that turns a leaked key into a direct and often irreversible loss of funds. Use this page alongside the parent Exchange & Platform Security hub for the broader set of exchange-side protections, and the token allowance checker tools guide for the equivalent permission-review habit applied to on-chain approvals.

Related Reading

• Exchange & Platform Security — the parent hub covering the broader set of exchange account and platform security practices beyond API key permissions.
• Withdrawal whitelist addresses — a complementary exchange-side control that restricts where funds can be withdrawn to, independent of API key permissions.
• Token allowance checker tools — the equivalent permission-review habit applied to on-chain token approvals granted to decentralized applications rather than exchange API keys.
• Scam & Security Center — the top-level hub for phishing, approvals, and exchange-security guides across the site.

Frequently Asked Questions