How should a Python app handle secrets safely?

A Python application should never hold secrets in source files or images. Fetch them at runtime from a central secrets store, give each service its own narrowly scoped credential, rotate on a schedule, log every access, and have a revoke-then-rotate routine ready for the day one leaks.

The guidance below follows the OWASP Secrets Management Cheat Sheet and applies it to common Python setups.

Where do Python secrets usually leak?

Not in clever attacks. They leak in a settings module committed with a real key, a Dockerfile with an ENV line, a notebook output cell, a test fixture copied from production, a debug log that prints the config object, and a requirements file that points at a private index with a token in the URL.

Constructed example: a Django project keeps a database password in settings.py "just for staging". The repository is later made public for a conference talk. The password is now in history forever, and deleting the line in a new commit changes nothing.

What does a better pattern look like?

OWASP recommends a centralized secrets management solution with standard ways for teams to use it. For a Python service that means the app starts, authenticates to the store with its own workload identity, reads what it needs into memory, and never writes it to disk or logs.

Read configuration through one small function, so there is one place to audit. Have it fail loudly when a value is missing instead of falling back to a default that someone once hard coded. Keep non-secret settings, such as feature flags, in ordinary config so the secret path stays short and reviewable.

What about environment variables?

They are common and better than source code, but OWASP's container guidance says to avoid them where possible because they are widely visible: child processes inherit them, crash reporters capture them, and some tooling prints them. Where you can, prefer secrets mounted as files or fetched from the store at runtime, injected at deployment and not at build time.

How should secrets be scoped and rotated?

OWASP asks for least privilege per secret and tight control of roles that can read or pass them. One credential per service and per environment means a leak has a small blast radius. It also recommends short-lived dynamic credentials where the provider supports them, with automated rotation so a stolen value dies quickly. Remember that restarting an app does not revoke a credential; revocation comes from lease expiry or an explicit call.

How do you catch leaks before they ship?

Run secret detection in pre-commit and in CI, as OWASP suggests, and scan history when you adopt it. Add the usual patterns to .gitignore, such as local env files and key files. Treat the CI system as production: avoid large shared secrets, check that pull requests from forks cannot read them, and make sure job output does not echo them.

What to do when one leaks

1. Revoke the exposed credential first, then rotate it through an automated process.
2. Remove it from code, logs, build artifacts and chat, knowing that history may still hold copies.
3. Check access logs for use you did not make.
4. Record who was alerted and what was done.
5. Add a detection rule so the same pattern is caught next time.

What to do this week

1. Search the repository and its history for keys, tokens and connection strings.
2. Move each one into a central store and read it at runtime through a single function.
3. Give every service its own credential and remove shared ones.
4. Turn on secret scanning in pre-commit and CI.
5. Write the leak response steps above in your runbook.

Safeguard has a secrets scanning capability and a free in-browser scan at gold.safeguard.sh/scan for checking dependencies, which complement the habits above.

Quick check

Sources

• OWASP Secrets Management Cheat Sheet

Last reviewed: 18 October 2026.