Environment variables for secrets in Django - Deep Dive

Overview - Environment variables for secrets

What is it?

Environment variables for secrets are a way to store sensitive information like passwords, API keys, or secret tokens outside your Django code. Instead of writing secrets directly in your code files, you keep them in your computer's environment settings. This keeps your secrets safe and makes your app easier to move between different computers or servers.

Why it matters

Without using environment variables for secrets, sensitive data can accidentally be shared publicly, like when uploading code to the internet. This can lead to security breaches and unauthorized access. Using environment variables keeps secrets hidden and secure, helping protect your users and your app's integrity.

Where it fits

Before learning this, you should understand basic Django settings and how to run a Django project. After this, you can learn about deploying Django apps securely and using secret management tools or services.

Mental Model

Core Idea

Environment variables act like secret envelopes outside your code that hold sensitive information safely and separately.

Think of it like...

Imagine your Django app is a locked box, and environment variables are secret notes you keep in a safe place outside the box. When you need the secret, you open the safe, read the note, and use it without ever putting the note inside the box where others might see it.

┌─────────────────────┐
│  Django Application  │
│  ┌───────────────┐  │
│  │   Code Files  │  │
│  └───────────────┘  │
│          │          │
│          ▼          │
│  ┌────────────────┐│
│  │ Environment    ││
│  │ Variables      ││
│  │ (Secrets)      ││
│  └────────────────┘│
└─────────────────────┘

Build-Up - 7 Steps

1

Foundation

What are environment variables?

Concept: Introduce environment variables as key-value pairs stored outside code.

Environment variables are settings stored by your operating system or hosting environment. They hold information like usernames, passwords, or configuration options. You can access them in Django using Python's os module, for example: os.environ.get('MY_SECRET').

Result

You understand that environment variables are separate from your code and can be accessed safely.

Knowing that environment variables live outside your code helps you keep secrets safe and your code clean.

2

Foundation

Why not put secrets in code?

Concept: Explain risks of hardcoding secrets directly in Django settings or code.

If you write secrets like passwords or API keys directly in your Django settings.py file, anyone who sees your code can see those secrets. This is risky especially if you share your code on public sites like GitHub. Also, changing secrets means editing code, which is error-prone.

Result

You realize that hardcoding secrets is unsafe and inconvenient.

Understanding the risks of exposing secrets motivates using safer methods like environment variables.

3

Intermediate

Setting environment variables locally

🤔Before reading on: do you think environment variables are set inside your Python code or outside it? Commit to your answer.

Concept: Learn how to set environment variables on your local machine for development.

On your computer, you can set environment variables in your terminal before running Django. For example, in Linux or Mac: export SECRET_KEY='your-secret'. In Windows Command Prompt: set SECRET_KEY=your-secret. Then in Django, access it with os.environ.get('SECRET_KEY').

Result

You can run your Django app locally using secrets stored safely outside your code.

Knowing how to set environment variables locally lets you keep secrets safe during development.

4

Intermediate

Using python-dotenv for easier management

🤔Before reading on: do you think environment variables can be stored in files or only set manually each time? Commit to your answer.

Concept: Introduce python-dotenv to load environment variables from a file automatically.

python-dotenv is a Python package that reads a .env file in your project folder and loads the variables into your environment. You create a .env file with lines like SECRET_KEY=your-secret. Then in your Django settings.py, you load it with from dotenv import load_dotenv; load_dotenv(). This way, you don't have to set variables manually every time.

Result

You can manage environment variables easily with a .env file during development.

Using python-dotenv simplifies secret management and reduces human error.

5

Intermediate

Accessing secrets safely in Django settings

🤔Before reading on: do you think accessing secrets with os.environ.get returns an error if the variable is missing, or returns None? Commit to your answer.

Concept: Learn how to read environment variables in Django settings and handle missing secrets.

In settings.py, import os and use os.environ.get('SECRET_KEY') to get your secret. If the variable is missing, it returns None, so you can provide a default or raise an error. For example: SECRET_KEY = os.environ.get('SECRET_KEY') or raise Exception('SECRET_KEY not set'). This prevents your app from running without required secrets.

Result

Your Django app safely reads secrets and fails early if they are missing.

Handling missing secrets prevents silent failures and security risks.

6

Advanced

Managing secrets in production environments

🤔Before reading on: do you think production servers usually set environment variables manually or use secret management tools? Commit to your answer.

Concept: Explore how production servers and cloud platforms manage environment variables securely.

In production, environment variables are set by the hosting platform or server configuration, not manually. Platforms like Heroku, AWS, or Docker let you define secrets securely. This keeps secrets out of code and version control. You also avoid exposing secrets in logs or error messages by careful configuration.

Result

You understand how to keep secrets safe and separate in real-world deployments.

Knowing production secret management practices is key to building secure, scalable apps.

7

Expert

Avoiding common secret management pitfalls

🤔Before reading on: do you think committing .env files to version control is safe or risky? Commit to your answer.

Concept: Learn advanced best practices and common mistakes to avoid with environment variables.

Never commit .env files or any secret files to public repositories. Use .gitignore to exclude them. Also, avoid printing secrets in logs or error messages. Rotate secrets regularly and use dedicated secret management services when possible. Understand that environment variables can be leaked if your server is compromised, so combine with other security layers.

Result

You can confidently manage secrets without accidental leaks or security holes.

Mastering secret management prevents costly security breaches and builds trust.

Under the Hood

Environment variables are stored by the operating system as key-value pairs accessible to running programs. When Django starts, it inherits these variables from the OS environment. The os module in Python reads these variables from the process environment. This separation means secrets never appear in code files or version control, reducing exposure risk.

Why designed this way?

This design separates configuration from code, following the Twelve-Factor App principles. It allows the same code to run in different environments (development, testing, production) with different secrets without changes. Alternatives like hardcoding secrets or config files risk accidental exposure and reduce flexibility.

┌───────────────┐       ┌─────────────────────┐
│ Operating     │       │ Django Application   │
│ System Env   │──────▶│ os.environ.get(...)  │
│ Variables    │       │ (Reads secrets)      │
└───────────────┘       └─────────────────────┘

Myth Busters - 4 Common Misconceptions

Quick: Do environment variables automatically encrypt your secrets? Commit to yes or no.

Common Belief: Environment variables keep secrets encrypted and fully secure by default.

Reality: Environment variables are stored as plain text in the OS environment and are not encrypted automatically.

Why it matters: Assuming encryption leads to lax security practices, risking secret leaks if the server is compromised.

Quick: Can you safely commit your .env file with secrets to a public GitHub repo? Commit yes or no.

Common Belief: It's okay to commit .env files because they are local and won't be shared widely.

Reality: Committing .env files exposes secrets publicly, risking unauthorized access.

Why it matters: This mistake is a common cause of data breaches and lost trust.

Quick: Does os.environ.get('SECRET') raise an error if SECRET is missing? Commit yes or no.

Common Belief: os.environ.get throws an error if the environment variable is missing.

Reality: os.environ.get returns None if the variable is missing; it does not raise an error.

Why it matters: Not handling missing secrets can cause your app to run insecurely or fail unexpectedly.

Quick: Are environment variables the only way to manage secrets securely? Commit yes or no.

Common Belief: Environment variables are the only secure method to manage secrets in Django.

Reality: There are other secure methods like secret management services (AWS Secrets Manager, Vault) that offer encryption and rotation.

Why it matters: Relying only on environment variables may miss advanced security features needed in large or sensitive applications.

Expert Zone

1

Environment variables are process-specific; child processes inherit them but changes at runtime do not propagate back to the OS environment.

2

Using environment variables for secrets works well but combining them with encrypted secret stores adds an extra security layer.

3

Beware of environment variable exposure in error tracebacks or debug logs, which can leak secrets unintentionally.

When NOT to use

For very large or complex systems, environment variables alone are insufficient. Use dedicated secret management tools like HashiCorp Vault or cloud provider secret managers that support encryption, access control, and automatic rotation.

Production Patterns

In production, secrets are injected into containers or server environments via deployment pipelines or platform dashboards. Apps read them at startup without code changes. Teams use .env files only for local development and testing, never in production.

Connections

Twelve-Factor App Configuration

Environment variables are the recommended way to handle configuration in the Twelve-Factor App methodology.

Understanding environment variables helps grasp how modern apps separate config from code for portability and security.

Operating System Process Environment

Environment variables are part of the OS process environment that programs inherit when they start.

Knowing OS process environments clarifies why environment variables are accessible to running apps but not stored in code.

Physical Safe Deposit Boxes

Both environment variables and safe deposit boxes store valuables separately from daily use items for security.

Recognizing this connection highlights the importance of separating secrets from code to reduce risk.

Common Pitfalls

#1 Committing .env file with secrets to version control.

Wrong approach:

git add .env
git commit -m 'Add env file with secrets'
git push origin main

Correct approach:

Add .env to .gitignore
Only commit code without secrets
Set environment variables separately on each machine

Root cause:

Not understanding that .env files contain sensitive data that should never be shared publicly.

#2 Accessing environment variables without handling missing values.

Wrong approach:

SECRET_KEY = os.environ.get('SECRET_KEY')
# No check for None

Correct approach:

SECRET_KEY = os.environ.get('SECRET_KEY')
if not SECRET_KEY:
raise Exception('SECRET_KEY not set')

Root cause:

Assuming environment variables are always set leads to silent failures or insecure defaults.

#3 Printing secrets in debug logs or error messages.

Wrong approach:

print(f"Secret key is {os.environ.get('SECRET_KEY')}")

Correct approach:

# Never print secrets
logger.info('Starting app without revealing secrets')

Root cause:

Not realizing that logs can be accessed by others, exposing sensitive information.

Key Takeaways

Environment variables keep secrets outside your Django code, improving security and flexibility.

Never hardcode secrets or commit secret files to version control to avoid accidental exposure.

Use python-dotenv or similar tools to manage environment variables easily during development.

Always handle missing environment variables in your code to prevent silent failures.

In production, rely on platform or secret management tools to inject secrets securely.

Practice

1. Why is it recommended to use environment variables for secrets in a Django project?

easy

A. To keep sensitive information out of the code and version control

B. To make the code run faster

C. To avoid writing settings.py file

D. To automatically generate secret keys

Solution

1. Step 1: Understand the purpose of environment variables

   Environment variables store sensitive data outside the code, so secrets are not exposed in files or repositories.

2. Step 2: Recognize the security benefit

   Keeping secrets out of code prevents accidental leaks when sharing or publishing code.

3. Final Answer:

   To keep sensitive information out of the code and version control -> Option A

4. Quick Check:

   Secrets outside code = safer projects [OK]

Hint: Secrets belong outside code, use env vars [OK]

Common Mistakes:

• Thinking env vars speed up code
• Believing env vars replace settings.py
• Assuming env vars auto-generate secrets

2. Which of the following is the correct way to read an environment variable named DJANGO_SECRET_KEY in Django's settings.py?

easy

A. secret_key = os.getenv('DJANGO_SECRET_KEY')

B. secret_key = os.environ['DJANGO_SECRET_KEY']()

C. secret_key = getenv.os('DJANGO_SECRET_KEY')

D. secret_key = os.get('DJANGO_SECRET_KEY')

Solution

1. Step 1: Recall correct syntax for environment variable access

   In Python, os.getenv('VAR_NAME') safely reads environment variables.

2. Step 2: Check each option for syntax correctness

   secret_key = os.getenv('DJANGO_SECRET_KEY') uses correct syntax. secret_key = os.environ['DJANGO_SECRET_KEY']() wrongly calls os.environ as a function. secret_key = getenv.os('DJANGO_SECRET_KEY') reverses function and module. secret_key = os.get('DJANGO_SECRET_KEY') uses a non-existent method.

3. Final Answer:

   secret_key = os.getenv('DJANGO_SECRET_KEY') -> Option A

4. Quick Check:

   Use os.getenv('VAR') to read env vars [OK]

Hint: Use os.getenv('VAR_NAME') to read env vars [OK]

Common Mistakes:

• Calling os.environ like a function
• Swapping function and module names
• Using non-existent os.get method

3. Given this code snippet in settings.py:

import os
SECRET_KEY = os.getenv('DJANGO_SECRET_KEY', 'defaultkey')
print(SECRET_KEY)

What will be printed if the environment variable DJANGO_SECRET_KEY is not set?

medium

A. An empty string will be printed

B. An error will occur because the variable is missing

C. None will be printed

D. The string 'defaultkey' will be printed

Solution

1. Step 1: Understand os.getenv default parameter

   If the environment variable is missing, os.getenv returns the default value provided as the second argument.

2. Step 2: Apply to given code

   Since DJANGO_SECRET_KEY is not set, os.getenv returns 'defaultkey', which is printed.

3. Final Answer:

   The string 'defaultkey' will be printed -> Option D

4. Quick Check:

   Missing env var returns default value [OK]

Hint: os.getenv returns default if env var missing [OK]

Common Mistakes:

• Expecting error if env var missing
• Thinking None is returned without default
• Assuming empty string is returned

4. You wrote this in settings.py:

import os
SECRET_KEY = os.getenv(DJANGO_SECRET_KEY)

But when running the server, you get a NameError. What is the problem?

medium

A. SECRET_KEY must be set manually, not from env vars

B. DJANGO_SECRET_KEY should be a string in quotes

C. os.getenv cannot be used in settings.py

D. You forgot to import dotenv

Solution

1. Step 1: Identify the cause of NameError

   NameError means the name DJANGO_SECRET_KEY is not defined as a variable in the code.

2. Step 2: Correct usage of os.getenv

   Environment variable names must be passed as strings, so it should be os.getenv('DJANGO_SECRET_KEY').

3. Final Answer:

   DJANGO_SECRET_KEY should be a string in quotes -> Option B

4. Quick Check:

   Env var names need quotes in os.getenv [OK]

Hint: Put env var names in quotes for os.getenv [OK]

Common Mistakes:

• Passing env var name without quotes
• Thinking os.getenv is disallowed in settings.py
• Assuming dotenv import is mandatory

5. You want to securely manage different secret keys for development and production in Django using environment variables. Which approach is best?

hard

A. Hardcode the production secret key in settings.py and use a dummy key for development

B. Store all secrets in a JSON file inside the project and read it in settings.py

C. Set DJANGO_SECRET_KEY differently in each environment and read it with os.getenv('DJANGO_SECRET_KEY') in settings.py

D. Use the same secret key for all environments to avoid confusion

Solution

1. Step 1: Understand environment-specific secrets

   Each environment (development, production) should have its own secret key to keep them isolated and secure.

2. Step 2: Use environment variables for flexibility

   Setting DJANGO_SECRET_KEY differently in each environment and reading it via os.getenv allows safe, flexible secret management without code changes.

3. Final Answer:

   Set DJANGO_SECRET_KEY differently in each environment and read it with os.getenv('DJANGO_SECRET_KEY') in settings.py -> Option C

4. Quick Check:

   Env vars per environment keep secrets safe and flexible [OK]

Hint: Use env vars per environment for secrets [OK]

Common Mistakes:

• Hardcoding secrets in code
• Sharing same secret across environments
• Storing secrets in project files