How to use API keys safely
- Author
- CRYPTO PORT Editorial
- Published
- Updated
- Reading time
- 6 min
In short
The basics for API keys are: grant the minimum permissions, restrict them to specific IP addresses, and issue a separate key per purpose. Above all, do not grant withdrawal permission unless you genuinely need it — if a leaked key cannot withdraw, the damage is contained. The secret is often shown only once at creation, so decide how you will store it beforehand.
Key points
- As a rule, do not enable withdrawals; if you must, pair it with a destination restriction
- Restrict the source IP addresses and allow only what is needed
- Issue a separate key per purpose and delete keys the moment they are no longer used
- The secret is usually displayed only once and cannot be shown again
Definition
Credentials that let an external program operate your exchange account. They are normally issued as a pair: a key, and a secret that must stay private.
Before creating a key, be clear about what it is for: reading balances and history, placing orders, or moving assets automatically. The purpose determines the permissions. Exchanges typically let you choose between read-only, trading and withdrawal scopes. Ticking everything 'just in case' is the most common and most expensive mistake here.
The principle is least privilege. Aggregating balances needs read-only. Running an automated strategy needs trading. Withdrawal permission has no justification unless you personally operate a system that moves assets out on a schedule. When a key without withdrawal rights leaks, the attacker can read data and place bad trades, but cannot take your assets — and that difference decides how bad the incident is. If you truly need withdrawals, always pair the key with a whitelist that limits destinations to addresses you registered.
Next, IP restriction. Most exchanges let you name the source addresses a key may be used from. If the program runs on a server, allow that server's address only; a leaked key is then useless from anywhere else. On a home connection with a changing address this can be impractical, but where it is possible it is one of the highest-value controls available.
Storage and operation are part of the design too. The secret is usually shown once, so failing to record it means reissuing. Keep it out of your code — use environment variables or a secrets manager — never commit it to a repository, and never let it appear in a screenshot or a screen share. Separate keys per purpose mean disabling one does not stop everything else.
Finally, review them periodically. List the keys you have issued and delete anything not currently in use; for the rest, confirm the permissions and IP restrictions still match the original design. If you suspect a key has leaked, delete first and investigate afterwards. A key can be recreated at any time; assets cannot.
Watch out for
- · Never hand an API key to another person or service. Offers to 'manage it for you' or to 'just plug it into a trading bot' are used to drain accounts
- · A leaked key with withdrawal rights lets an attacker simply take your assets. If you do not need that scope, do not grant it
- · API keys are not the same thing as a seed phrase or private key, but none of them should ever go to a third party. Exchanges do not ask for any of them
Frequently asked questions
I lost the secret. Can I see it again?
At most exchanges it cannot be shown again. Delete that key, issue a new one, set the permissions and IP restrictions again, and update whatever program was using it.