What’s the risk of weak API keys or tokens?

You've probably heard stories about developers accidentally committing API keys to a public GitHub repo. It happens more than you'd think, and when it's an ESP API key, the fallout goes way beyond a slap on the wrist from your manager.

An API key is essentially a password that lets software talk to your ESP without a human logging in. When your app needs to send a transactional email, it hands over that key to prove it's allowed. The problem is that keys are often created with broad permissions (full account access, not just "send email"), and once they're out in the wild, they work for anyone who has them until someone manually rotates them.

The most common ways keys get exposed are not especially exotic. A developer pushes code to a public repository with the key hardcoded in a config file. A key ends up in application logs that flow into a shared monitoring tool. Someone pastes it into a Slack message or a Postman collection that gets shared. Or it gets lifted through phishing. The key doesn't care who's using it. It just works.

Once an attacker has your API key, here's what they can do with it, depending on the permissions attached. They can send email at volume through your domain, which tanks your sender reputation fast. They can pull your subscriber list. They can modify sending configurations. They can delete suppression lists so complaints flood back in. This is essentially a full account takeover without ever needing your login password.

The good news is that fixing this is genuinely doable. A few things that make a real difference:

• Scope your keys tightly. If a key only needs to send transactional email, create it with only that permission. Not read, not write, not delete.
• Rotate regularly. Set a schedule. Monthly is common for production keys. When someone leaves the team, rotate immediately.
• Never hardcode keys in source files. Use environment variables or a secrets manager. Tools like HashiCorp Vault, AWS Secrets Manager, or even a simple .env file excluded from version control are all better than a key sitting in your codebase.
• Monitor for unusual activity. Most ESPs like Twilio SendGrid, Postmark, and Mailgun have activity logs. Watch for sends at odd hours, unfamiliar IP addresses, or sudden volume spikes.
• Audit what keys exist. Old keys that no one remembers creating are a real risk. Delete anything unused.

If you think a key has been compromised, revoke it first and ask questions later. Most ESP integrations can survive a key rotation if you update the new key in your environment quickly. The cost of a few minutes of downtime is much lower than the cost of a reputation hit from a spam run through your domain.

Not sure how to structure your key permissions or set up monitoring? Our SOS hotline is free and we're happy to walk through it with you.