How to Protect API Keys in a Python Script (What Actually Works)

Start with the obvious version — a key sitting in the source:

import requests

API_KEY = "sk-live-9f83a1c47e5b2d60"

def fetch(u):
    return requests.get(u, headers={"Authorization": f"Bearer {API_KEY}"})

"But I'll ship the compiled .pyc, not the .py." That changes nothing. I compiled it, then searched the bytecode. The key is stored verbatim in the code object's constants and shows up in a plain byte search of the file:

Key sits in the compiled code object's co_consts:  True
Key found by a raw byte search of the .pyc blob:    True

These are the three suggestions that come up most often. I tested each by reversing it:

a) base64-encoded key -> reversed with one call:            True
b) moved to config.py -> key still readable in the file:    True
c) XOR-'encrypted' key + the XOR key both ship, decrypts:   True

The pattern is the same every time: encoding is not encryption, and any "encryption" whose key also ships is just encoding with extra steps. If your program can decode it without asking anyone, so can the person holding your program.

Obfuscation is the honest middle case, so let me be precise about it. I ran the key-bearing script through our own Python Obfuscator (AST rename + string encryption) and checked the result:

plaintext key visible in obfuscated source:   False
key found by a naive substring search:         False
runs; printed value equals the original key:   True

So obfuscation does do something real: the key is no longer sitting in the file as plaintext, so a grep, a strings dump, or a quick decompile of the constants turns up nothing. That raises the cost of a casual grab. But look at the last line — the program still runs and reconstructs the exact key in memory, because it has to in order to use it. A determined attacker with a debugger or a memory dump gets it back.

The whole game is keeping the key out of the artifact you distribute. Here's the ladder, from the baseline every project should do, to what a distributed app needs.

1. Environment variables (the baseline). Read the key from the environment at runtime; it never appears in your code. Same script, key removed:

import os, requests

API_KEY = os.environ["APP_API_KEY"]   # read at runtime, never in the code

def fetch(u):
    return requests.get(u, headers={"Authorization": f"Bearer {API_KEY}"})

Key present in app.py source:            False
Key present in the compiled .pyc bytes:  False
Run with APP_API_KEY set in env  -> resolved at runtime, len: 24
Run WITHOUT the env var          -> KeyError: 'APP_API_KEY'

The key is absent from both the source and the bytecode, and the program only works when the environment supplies it. That's the whole idea. Use os.environ["NAME"] when the key is required (fail loudly), or os.getenv("NAME", default) when it's optional.

2. A `.env` file for local development (with python-dotenv). Typing export on every shell gets old, so keep local secrets in a .env file and load them — but the .env itself must be git-ignored, because it holds the real key in plaintext:

APP_API_KEY=sk-live-9f83a1c47e5b2d60

from dotenv import load_dotenv
import os

load_dotenv()                      # reads .env into the environment
API_KEY = os.environ["APP_API_KEY"]

I ran this with python-dotenv 1.2.2 and it loaded the value from .env into the environment as expected. The .env pattern gives you the convenience without ever committing the secret — as long as .gitignore contains .env from day one.

3. A secrets manager (production). On a server, load secrets at boot from a dedicated store — AWS Secrets Manager, Google Secret Manager, HashiCorp Vault, Doppler, or your platform's built-in "environment secrets." Your code asks for the secret by name; the value lives outside the repo and the image, is access-controlled, and is auditable and rotatable.

4. Distributed apps: don't ship the key at all. Environment variables and secrets managers solve the *server* case, where you control the machine. If you're shipping a desktop tool, a script to customers, or anything that runs on a user's machine, no amount of hiding is safe — see every test above. The real fix is to put the key on your own backend and proxy the calls: your app calls *your* server, your server holds the key and talks to the third-party API. The secret never leaves a machine you control.

1. Client app → your backend (authenticated as the user)
2. Your backend (holds the API key) → third-party API
3. Response flows back through your backend to the client

Removing a key in a new commit does not remove it from git history — it's still there in every clone and on GitHub. Two steps, in this order:

1. Rotate the key immediately. Revoke the exposed one and issue a new one. Assume the old key is compromised the moment it hit a remote — scanners find committed keys within minutes.
2. Then scrub history with git filter-repo (or the BFG Repo-Cleaner) and force-push, so the value is gone from past commits. Tools like trufflehog and gitleaks scan a repo (and its history) for secrets — run one in CI so this never ships again.

• Never hard-code a key — not in the source, not in a config.py, not base64'd.
• Read secrets from the environment (os.environ / os.getenv).
• Use a git-ignored `.env` locally (python-dotenv); commit a .env.example with names only.
• Use a secrets manager in production; rotate keys on a schedule.
• For anything running on a user's machine, proxy through your backend — don't ship the key.
• Scope keys to least privilege, and scan your repo + history with gitleaks/trufflehog.
• Use obfuscation to protect logic, not to hide secrets — those are different jobs.

Related reading: protecting Python source code (where obfuscation genuinely helps), Python string encryption tested, and is Python obfuscation secure?.