3. The hardcoding trap

Now that you have a key, the tempting first move is to paste it straight into your Python file and start making requests. The code will run, the requests will succeed, and everything will look fine. That's exactly what makes the pattern dangerous, it hides the break until something else goes wrong.

Hardcoding credentials is the single most common security mistake in software development. It seems harmless when you're learning or knocking out a quick prototype. But "temporary" has a way of becoming permanent, and permanent hardcoded credentials lead to breaches that cost real money and damage real reputations. Before we reach for the fix, let's look at exactly how the pattern breaks, not as abstract theory, but as concrete scenarios you will encounter.

What hardcoding looks like

Save this as hardcoded_key.py at the project root. It runs. It returns valid weather data. And it creates a vulnerability that could cost you money or your job:

import requests

# DO NOT ship code like this. See the four failure modes below.
API_KEY = "a7d4f2c8e1b9f3d6a8c4e7f2b5d8c3a9"


def get_weather(city):
    """Fetch current weather for a city."""
    url = "https://api.openweathermap.org/data/2.5/weather"
    params = {
        "q": city,
        "appid": API_KEY,
        "units": "metric",
    }

    response = requests.get(url, params=params, timeout=10)
    if response.ok:
        data = response.json()
        temp = data["main"]["temp"]
        description = data["weather"][0]["description"]
        return f"{city}: {temp}°C, {description}"
    return "Failed to get weather data"


print(get_weather("Dublin"))

Run it and it works. The trouble isn't with the Python or the API; it's with what happens to the file next.

Four ways this breaks

Git history is forever

You write the code with the key inline. It works. You commit. Now the key is in your repository's history, and not just in the latest commit. Even if you remove it in the next commit, it still lives in the history. Anyone who clones the repo can read it. If the repo is public, so can anyone on the internet.

Automated scanners continuously walk GitHub, GitLab, and Bitbucket looking for patterns that smell like API keys. They find fresh commits in minutes. If the key works, they use it, often to spin up cryptocurrency miners on your cloud account, or to resell your API quota. You notice when the bill arrives.

Sharing code = sharing credentials

You want help debugging, so you paste the file into a Slack channel, a Discord, or Stack Overflow. You forget the key is hardcoded on line 4. Everyone in that channel now has your credentials. Editing the message later doesn't help, the original is cached, screenshotted, or already copied by someone else.

Or a coworker asks to see your code. You email the file. Now your key sits in their inbox, their email provider's servers, and whatever backup system their laptop uses. They aren't going to notice; they're looking at the bug, not at the constants at the top of the file.

Rotation becomes impossible

The day comes when you need to rotate the key, maybe the old one leaked, maybe company policy requires a ninety-day cycle. With a hardcoded key, rotation means finding every file where the string lives. Was it just this file? Did past-you copy-paste it into a side project? Does it exist on your work laptop and your personal laptop?

Every copy needs to be found and replaced by hand. You can't automate it: the key is scattered across files, projects, and machines. Miss one and the exposure remains.

Different environments need different keys

Professional development runs in at least three environments, local, staging, and production, and each should use a different key with different permissions and different rate limits. Hardcoded keys force you to maintain multiple copies of the same code, one per environment, and deployment mistakes that put production code in front of a dev key (or worse, the reverse) become depressingly routine.

The fix is a pattern every professional toolchain agrees on: keep credentials out of source code, in a separate configuration layer, and have the code look the value up by name at runtime. That layer is called the environment, and the next section shows you how to put your key there.