Introduction
In Part 1, we broke down why Exchange API keys are becoming a major security risk:
They’re powerful, widely used in automated trading, and frequently handled insecurely.
In Part 2, we look at existing mitigation strategies and why, despite best intentions, they’re not enough to protect your keys against the growing threats, which we witness every other week in Web3.
Current Security Measures - Not Enough For Modern Attackers
Security teams often turn to common strategies when dealing with Exchange API keys—such as:
- IP allowlists
- Permission scopes (e.g. “read-only,” “no withdrawal”)
- Secrets managers
- Activity monitoring and alerting tools
The problem?
Security teams often lean on conventional security solutions, like the ones mentioned above. These controls seem solid on paper but often fail in real-world scenarios. Attackers are not only aware of these guardrails—they’ve adapted to work around them.
Let’s dive in and explain where current solutions fall short.
1. Why IP Restrictions Don’t Work
Restricting API key usage to specific IP addresses is a widely-used security solution in the space, that is solid in theory.
In reality:
- Attackers who gain access to your cloud environment can operate within your allowed IP addresses.
- Dynamic cloud infrastructure (with autoscaling, rotating IPs) makes allowlists hard to maintain.
- Sophisticated attackers can spoof trusted IPs
In short: attackers don’t care about your firewall if they’re already inside the house.
2. “No Withdrawal” Permissions ≠ No Damage
Setting your API keys to “no withdrawal” is good hygiene. However there are many different ways that attackers can still cause damage or still funds, including:
- Trading against a low-volume pair to steal the funds
- Malicious trades
- Market manipulation
- Forced slippage and loss
- Data tampering or poisoning of trading logic
3. Secrets Managers Are a Double-Edged Sword
Storing API keys in a secrets manager (like AWS Secrets Manager or Vault) is a good first step.But here’s what often gets overlooked:
The most vulnerable moment for an API key is the split-second it's retrieved from the secrets manager and loaded into memory.
That’s the moment sophisticated attackers aim for. They hook into running processes, extract keys directly from memory, and bypass the secrets manager entirely.
It’s not about where you store the key—it’s about how you use it.
4. Fireblocks & Similar Platforms: Useful For Some Use Cases, But Not Enough
Solutions like Fireblocks offer strong protection for transfers and withdrawals, often with great UI and policy enforcement capabilities.
But when it comes to automated, programmatic use cases—like trading bots, backend strategies, or portfolio rebalancing—these platforms simply don’t fit.
They're not built for API-native high-performancet environments, and that’s where many teams still end up exposing their keys directly.
5. Monitoring Is Not Prevention
You can monitor key usage. You can set up alerts. But once an attacker is in, they move fast. By the time a suspicious action is flagged, it’s often too late.
Monitoring is important—but it's not a security control. It’s just a reactive measure for an existing leak.
Bottom Line: Storage ≠ Security
Most solutions focus on storing API keys securely. Others focus on securing certain functions.
But Exchange API keys are used frequently, by backend systems, bots, and automated trading infrastructure. They’re most vulnerable at the point of use—and that’s where most solutions leave a gap.
Coming Up Next
In Part 3, we’ll introduce a new holistic and modern solution for securing Exchange API keys, designed for programmable trading, that addresses all stages - import, storage, the moment of use and remediation in risk scenarios.
