Python Secure Coding Practices — Core Concepts

The Secure Coding Mindset

Secure coding isn’t a phase of development — it’s a style of development. Every function you write either makes the system safer or introduces a potential weakness. The goal is making the safe path the default path.

1. Input Validation and Sanitization

Every piece of data entering your program from the outside world — HTTP requests, file uploads, database reads, environment variables, API responses — is potentially hostile.

Allowlist over blocklist. Don’t try to enumerate every bad input. Define what good input looks like and reject everything else. An email field should match a pattern; an age field should be an integer between 0 and 150.

Validate at the boundary. Check inputs when they enter your system, not deep inside business logic. Pydantic models in FastAPI, Django forms, and marshmallow schemas all enforce structure at the API boundary.

Type coercion isn’t validation. int("42") succeeds, but int("42; DROP TABLE users") raises an error. Type conversion catches format issues but not logical ones. Range checks, pattern matching, and business rules are still needed.

2. Secret Management

Never hardcode secrets. No API keys in source code, no passwords in configuration files committed to Git. Once a secret enters version control, it exists in every clone, fork, and backup forever.

Use environment variables or secret managers. os.environ["DATABASE_URL"] for simple setups. HashiCorp Vault, AWS Secrets Manager, or GCP Secret Manager for production. The python-dotenv package loads .env files for local development — but .env must be in .gitignore.

Rotate secrets regularly. Assume every secret will eventually leak. Regular rotation limits the window of exposure. Design systems to support rotation without downtime (accept both old and new keys during a transition window).

3. Principle of Least Privilege

Database users should have only the permissions they need. The web app’s database user shouldn’t have DROP TABLE privileges. Use read-only connections where possible.

File system access should be scoped. If your app processes uploads, it shouldn’t have write access to system directories. Use a dedicated upload directory with restricted permissions.

API scopes should be minimal. When requesting OAuth tokens, ask for the minimum scopes needed. A service that reads user profiles doesn’t need write access to their email.

4. Dependency Security

The average Python project has 40+ transitive dependencies. Each one is code you didn’t write, running with your application’s permissions.

Audit regularly with pip-audit or safety check. These tools compare your installed packages against databases of known vulnerabilities.

Pin versions in requirements.txt or pyproject.toml. Unpinned dependencies can change unexpectedly, introducing both bugs and vulnerabilities.

Review new dependencies before adding them. Check: how many maintainers? When was the last release? Does it have a security policy? A popular package with one maintainer and no releases in two years is a supply chain risk.

5. Error Handling and Information Leakage

Never expose stack traces in production. Stack traces reveal file paths, library versions, database schemas, and internal logic — everything an attacker needs for reconnaissance.

Use generic error messages externally. “An error occurred” to the user; detailed information to your logging system. Django’s DEBUG = False and Flask’s app.debug = False enforce this separation.

Log security events. Failed logins, permission denials, validation failures, and unexpected exceptions should all generate log entries with enough context to detect attacks but without sensitive data (no passwords, tokens, or PII in logs).

6. Secure Defaults

HTTPS everywhere. Redirect HTTP to HTTPS. Set Secure flag on cookies. Use HSTS headers to prevent downgrade attacks.

Parameterized queries always. Never concatenate user input into SQL, even for “simple” queries. ORMs parameterize by default — use them.

Auto-escaping in templates. Django and Jinja2 auto-escape HTML output by default. Never disable this globally. When you must output raw HTML, sanitize it with a library like bleach or nh3.

Session security. Use HttpOnly cookies (inaccessible to JavaScript), Secure flag (HTTPS only), SameSite attribute (prevents CSRF on modern browsers), and short expiration times.

7. Cryptography Basics

Don’t invent your own. Use established libraries (cryptography, bcrypt, argon2-cffi) instead of hand-rolling encryption or hashing schemes.

Hash passwords with slow functions. bcrypt, argon2, or PBKDF2 with high iteration counts. Never SHA-256 a password directly.

Use secrets, not random. For tokens, keys, and anything security-sensitive, use the secrets module. The random module is for games and simulations.

Common Misconception

“Security is the security team’s job.” In modern development, security is every developer’s responsibility. The security team sets policy and audits — but the developer writing the code is the first and most important line of defense. A security review can’t catch every flaw; writing secure code by default prevents most flaws from existing in the first place.

The one thing to remember: secure coding is a collection of small, consistent habits — validate inputs, protect secrets, minimize privileges, update dependencies, and handle errors carefully — that compound into genuinely resilient software.