Environment Variables and Secrets: Keeping Your API Keys Out of the Wrong Hands

Will

What secrets management actually means

Secrets management is the practice of storing sensitive credentials API keys, database passwords, payment gateway tokens securely, and keeping them out of your code and your version control. Done well, it means the people and systems that need a credential can get it, and nobody else can.

Most breaches in this area are not sophisticated. They happen because a key ended up somewhere it should never have been, like a public code repository or a screenshot in a support ticket.

The good news is that this is a solved problem. It just needs a small amount of discipline built into how your site or application is developed and deployed.

Why keys leak in the first place

The most common cause is hard-coding a credential directly into the application, then committing it to a repository. Even a private repo is risky, because access changes over time and history is hard to scrub.

Other leaks come from mundane places: a key pasted into a chat, left in a config file on a shared drive, or reused across several projects so one exposure compromises all of them.

Automated bots constantly scan public code hosts for exposed keys. A leaked cloud or payment key can be found and abused within minutes, sometimes running up thousands in charges before anyone notices.

How it should be done

Credentials should live in environment variables or a dedicated secrets store, never in the codebase itself. Your application reads them at runtime, so the actual values stay out of version control entirely.

For anything beyond a simple site, a managed secrets service such as those built into your hosting or cloud provider adds encryption at rest, access controls, and an audit trail of who accessed what. That trail matters when something goes wrong.

Different environments should use different keys. Your staging site should never share credentials with production, so a mistake in testing can never touch live customer data or real payments.

Rotation, access, and the human factor

Keys should be rotatable without downtime, so that if one is exposed you can replace it quickly and calmly. If rotating a key means editing code and redeploying, people put it off and that delay is where damage happens.

Limit who and what can read each secret. A marketing analytics key does not need access to your database credentials, and most team members do not need production secrets at all.

When someone leaves or a contractor finishes, their access should be revoked and any secrets they handled rotated. This is unglamorous housekeeping, but it closes a door attackers rely on being left open.

The honest caveat

Secrets management is not a silver bullet. It protects credentials, but it will not save you from a poorly written application, an unpatched dependency, or a phishing attack that hands over a login directly.

There is also a cost to doing it properly: a little more setup, a slightly steeper learning curve for whoever manages deployments. For a small brochure site with no integrations, a basic environment variable approach is perfectly sufficient you do not need enterprise tooling.

The right level of rigour scales with what you are protecting. The more customer data, payments, and third-party integrations involved, the more the investment pays for itself.

Getting the basics right from the start

If you are building anything that touches customer data or connects to other systems, it is worth handling secrets correctly from day one. Retrofitting good practice after a leak is far more painful than building it in.

We treat secrets management as a standard part of how we build and deploy, not an optional extra. It is one of those quiet foundations that never earns applause but saves a great deal of grief.

If you are unsure how your current site or application handles its credentials, we are happy to take a look and give you a straight answer about where the risks are.

Thinking about this for your business? Contact us.