Hardcoded secrets

Secrets like API keys, passwords, and tokens are meant to be, well, secret. But too often, developers embed them directly into source code, configuration files, or version control systems. This practice is known as hardcoding secrets, and it’s one of the most common security missteps in software development.

When secrets are hardcoded, they can accidentally leak through logs, error messages, or public repositories. Attackers scanning open-source projects regularly find these gems, leading to data breaches, service abuse, or total system compromise.

In this lesson, you’ll learn why hardcoding secrets is risky, how attackers discover these mistakes, and practical strategies to keep your applications safe and your secrets... secret. We'll walk through some bad examples and then talk about mitigation strategies to correct our errors!

Deep in the mystical land of Codeshire, a slightly scatterbrained wizard named Archibald the Absentminded has invented a magical weather bot called Stormy. Stormy connects to weatherwand.xyz, a powerful enchanted weather forecasting service.

WeatherWand offers two types of API services:

• Free tier: limited forecasts, simple sun/rain predictions, and a cap of 100 calls per day.
• Premium tier: advanced features like hour-by-hour forecasts, storm tracking, and real-time dragon flight advisories, with no usage limits—but at a hefty price per request.

Archibald, eager to impress his fellow villagers, signed up for a premium WeatherWand API key to make sure Stormy always gave the most accurate predictions. But in his haste to share his project with the world, he made a critical mistake:

Almost immediately, someone discovers Stormy’s repository and notices the hardcoded API_KEY. How fast? Remarkably fast! There are a lot of bad actors who are actively scanning for secrets. And now that one of these bad actors have this applications key, they can start making thousands of premium API requests. And these are all billed to Archibald’s account!

Let’s look closer at Archibald’s mistake. By embedding the API key directly in the code, anyone with access to the repository can extract and abuse it.

Here’s the problematic code again

This API key is now:

• Stored in version control (visible to anyone with access).
• Bundled into builds and deployments (potentially discoverable by reverse engineering).
• Exposed if logs or errors print the variable.

Tools like truffleHog, GitLeaks, and even simple regex scans can uncover hardcoded secrets in public and private repositories. Attackers often automate scans across GitHub, GitLab, and Bitbucket, looking for patterns like:

Within minutes of pushing Stormy to GitScroll, Archibald’s API key was harvested by bots.

Hardcoded secrets can have devastating consequences for applications and businesses alike. When an API key, token, or password is embedded directly into the source code, it’s often just a matter of time before someone finds it. Especially if the code is stored in a public repository or shared with others.

One of the most common risks is service abuse. Attackers who discover a hardcoded API key can use it to send thousands of premium requests, racking up massive bills for the legitimate account holder. In Archibald’s case, the attacker drained his treasury by flooding WeatherWand with frivolous forecasts.

Another major concern is data exposure. Hardcoded database credentials or cloud storage tokens can give attackers direct access to sensitive information such as user data, intellectual property, or internal system configurations.

The consequences don’t end there. Infrastructure compromise is also a possibility if SSH keys or cloud provider tokens are accidentally leaked. Attackers can gain full control over servers, deploy their own malicious code, or pivot to other parts of the network.

Even if you realize the mistake and rotate the secret later, it may already be too late. Once a secret has been exposed, attackers can clone it instantly and continue using it until they’re blocked.

In short, hardcoding secrets turns your source code into a treasure map for attackers. Without proper handling, a single exposed key can unravel the security of your entire system.

To protect Stormy, Archibald updates his code to load secrets securely from the environment:

Archibald now stores the API key in a .env file for local development:

When Archibald is ready for production, if they are using a cloud provider, then providers like AWS, GCP, Azure encourage using their Secret Managers:

• AWS Secrets Manager / AWS Parameter Store
• Google Secret Manager
• Azure Key Vault

Services like Heroku, Vercel, Netlify, Render, AWS Elastic Beanstalk, etc. don’t use your .env file directly. Instead, you manually set environment variables in the platform’s dashboard or CLI.

They store them securely and inject them into your running process as actual environment variables. Your app can access them as if they came from a .env file.

Ready to banish hardcoded secrets from your projects? Here is some additional information:

• OWASP Cheat Sheet: Secrets Management - Best practices for handling secrets securely.
• Snyk: Prevent Secrets in Your Code - How to find and fix secret leaks using automated tools.
• TruffleHog - Open-source tool for scanning repos and finding sensitive keys.