Security checklist (manage.py check --deploy) in Django - Step-by-Step Execution

Concept Flow - Security checklist (manage.py check --deploy)

Run manage.py check --deploy

↓

Django runs security checks

↓

Check settings for security issues

↓

Report warnings or pass

↓

Fix reported issues

↓

Re-run check until no warnings

This flow shows how running the command triggers Django to check your project settings for common security issues and report warnings to fix.

Execution Sample

Django

python manage.py check --deploy

Runs Django's deployment security checks and reports any security warnings.

Execution Table

Step	Check Performed	Setting Checked	Result	Action Suggested
1	Check DEBUG mode	DEBUG	Warning: DEBUG=True	Set DEBUG=False for production
2	Check ALLOWED_HOSTS	ALLOWED_HOSTS	Warning: ALLOWED_HOSTS is empty	Add your domain names to ALLOWED_HOSTS
3	Check SECRET_KEY	SECRET_KEY	OK	No action needed
4	Check CSRF_COOKIE_SECURE	CSRF_COOKIE_SECURE	Warning: False	Set CSRF_COOKIE_SECURE=True
5	Check SESSION_COOKIE_SECURE	SESSION_COOKIE_SECURE	Warning: False	Set SESSION_COOKIE_SECURE=True
6	Check SECURE_HSTS_SECONDS	SECURE_HSTS_SECONDS	Warning: 0	Set SECURE_HSTS_SECONDS > 0
7	Check SECURE_CONTENT_TYPE_NOSNIFF	SECURE_CONTENT_TYPE_NOSNIFF	Warning: False	Set SECURE_CONTENT_TYPE_NOSNIFF=True
8	Check SECURE_BROWSER_XSS_FILTER	SECURE_BROWSER_XSS_FILTER	Warning: False	Set SECURE_BROWSER_XSS_FILTER=True
9	Check SECURE_SSL_REDIRECT	SECURE_SSL_REDIRECT	Warning: False	Set SECURE_SSL_REDIRECT=True
10	Check X_FRAME_OPTIONS	X_FRAME_OPTIONS	OK	No action needed
11	Check CSRF_COOKIE_HTTPONLY	CSRF_COOKIE_HTTPONLY	Warning: False	Set CSRF_COOKIE_HTTPONLY=True
12	Check SESSION_COOKIE_HTTPONLY	SESSION_COOKIE_HTTPONLY	OK	No action needed
13	Check SECURE_REFERRER_POLICY	SECURE_REFERRER_POLICY	Warning: Not set	Set SECURE_REFERRER_POLICY to a safe value
14	Check SECURE_PROXY_SSL_HEADER	SECURE_PROXY_SSL_HEADER	Warning: Not set	Set SECURE_PROXY_SSL_HEADER if behind proxy
15	Check default password validators	AUTH_PASSWORD_VALIDATORS	OK	No action needed
16	Summary	All checks	Warnings found	Fix all warnings before deployment

💡 Checks complete; warnings indicate settings to fix for secure deployment

Variable Tracker

Setting	Initial Value	After Fix 1	After Fix 2	Final
DEBUG	True	False	False	False
ALLOWED_HOSTS	[]	['example.com']	['example.com']	['example.com']
CSRF_COOKIE_SECURE	False	True	True	True
SESSION_COOKIE_SECURE	False	True	True	True
SECURE_HSTS_SECONDS	0	3600	3600	3600
SECURE_CONTENT_TYPE_NOSNIFF	False	True	True	True
SECURE_BROWSER_XSS_FILTER	False	True	True	True
SECURE_SSL_REDIRECT	False	True	True	True
CSRF_COOKIE_HTTPONLY	False	True	True	True
SECURE_REFERRER_POLICY	None	'no-referrer'	'no-referrer'	'no-referrer'
SECURE_PROXY_SSL_HEADER	None	('HTTP_X_FORWARDED_PROTO', 'https')	('HTTP_X_FORWARDED_PROTO', 'https')	('HTTP_X_FORWARDED_PROTO', 'https')

Key Moments - 3 Insights

Why does the check warn if DEBUG is True?

DEBUG=True shows detailed error pages to users, which can leak sensitive info. The execution_table row 1 shows this warning and suggests setting DEBUG=False for safety.

What happens if ALLOWED_HOSTS is empty?

An empty ALLOWED_HOSTS means Django will reject all incoming requests in production. Row 2 in the execution_table warns about this and suggests adding your domain names.

Why set CSRF_COOKIE_SECURE and SESSION_COOKIE_SECURE to True?

These settings ensure cookies are only sent over HTTPS, protecting them from being intercepted. Rows 4 and 5 show warnings if these are False.

Visual Quiz - 3 Questions

Look at the execution_table at step 6, what is the value of SECURE_HSTS_SECONDS?

A 0

B 3600

C True

D Not set

💡 Hint

Check the 'Result' column in row 6 of the execution_table.

At which step does Django check if SESSION_COOKIE_SECURE is set correctly?

A Step 3

B Step 9

C Step 5

D Step 12

💡 Hint

Look for SESSION_COOKIE_SECURE in the 'Setting Checked' column.

If you fix DEBUG to False, how does the variable_tracker show this change?

A DEBUG stays True

B DEBUG changes from True to False after Fix 1

C DEBUG changes from False to True after Fix 1

D DEBUG is removed

💡 Hint

Check the 'DEBUG' row in variable_tracker from 'Initial Value' to 'After Fix 1'.

Concept Snapshot

Run 'manage.py check --deploy' to scan your Django settings for security issues.
It checks DEBUG, ALLOWED_HOSTS, cookie security, SSL settings, and more.
Warnings tell you what to fix before deploying.
Fix all warnings to make your app safer in production.
Re-run the check until no warnings remain.

Full Transcript

The 'manage.py check --deploy' command runs a series of security checks on your Django project settings. It looks for common mistakes like leaving DEBUG mode on, not setting ALLOWED_HOSTS, or missing secure cookie flags. Each check reports if the setting is safe or needs fixing. For example, DEBUG should be False in production to avoid exposing sensitive info. ALLOWED_HOSTS must list your domain names to accept requests. Secure cookie settings ensure cookies are sent only over HTTPS. The command outputs warnings for each issue found. You fix these in your settings.py file and run the command again until no warnings remain. This helps you prepare your Django app for safe deployment.

Practice

1. What is the main purpose of running manage.py check --deploy in a Django project?

easy

A. To create a new database migration

B. To start the Django development server

C. To find security issues before deploying the site to production

D. To install required Python packages

Solution

1. Step 1: Understand the command's role

   manage.py check --deploy runs checks specifically for security and deployment readiness.

2. Step 2: Compare with other commands

   Other commands like migrations or server start do not check security issues.

3. Final Answer:

   To find security issues before deploying the site to production -> Option C

4. Quick Check:

   Security check = B [OK]

Hint: Remember: --deploy means check for production security [OK]

Common Mistakes:

• Confusing it with migration commands
• Thinking it starts the server
• Assuming it installs packages

2. Which of the following is the correct way to run the security deployment check in Django?

easy

A. python manage.py startapp --deploy

B. python manage.py migrate --deploy

C. python manage.py runserver --deploy

D. python manage.py check --deploy

Solution

1. Step 1: Identify the correct command syntax

   The command to check security issues is python manage.py check --deploy.

2. Step 2: Eliminate incorrect options

   Other commands like migrate, runserver, or startapp do not accept --deploy and serve different purposes.

3. Final Answer:

   python manage.py check --deploy -> Option D

4. Quick Check:

   Correct command syntax = A [OK]

Hint: Use 'check' command with --deploy flag for security checks [OK]

Common Mistakes:

• Using migrate or runserver with --deploy
• Mixing up command names
• Omitting 'python' or 'manage.py'

3. After running python manage.py check --deploy, you see a warning about SECURE_SSL_REDIRECT not being set. What will happen if you ignore this warning?

medium

A. Your site will not redirect HTTP requests to HTTPS, risking insecure connections

B. Your database migrations will fail

C. Your static files will not load

D. Your admin login page will be disabled

Solution

1. Step 1: Understand the warning about SECURE_SSL_REDIRECT

   This setting forces HTTP requests to redirect to HTTPS, securing data in transit.

2. Step 2: Consequences of ignoring the warning

   If not set, users can connect over insecure HTTP, exposing sensitive data.

3. Final Answer:

   Your site will not redirect HTTP requests to HTTPS, risking insecure connections -> Option A

4. Quick Check:

   SSL redirect missing = insecure HTTP allowed [OK]

Hint: SSL redirect warning means HTTP stays open, fix it! [OK]

Common Mistakes:

• Thinking it affects database or static files
• Assuming admin page disables automatically
• Ignoring HTTPS importance

4. You ran python manage.py check --deploy and got this error: "Your SECRET_KEY is not set or is insecure." What is the best way to fix this?

medium

A. Set a long, random SECRET_KEY in your settings and keep it secret

B. Remove the SECRET_KEY setting from your settings file

C. Set SECRET_KEY to 'django-insecure' for simplicity

D. Ignore the warning; it only affects development

Solution

1. Step 1: Understand SECRET_KEY importance

   SECRET_KEY is used for cryptographic signing and must be unique and secret.

2. Step 2: Fix by setting a strong, random key

   Generate a long random string and set it in settings securely; do not share it.

3. Final Answer:

   Set a long, random SECRET_KEY in your settings and keep it secret -> Option A

4. Quick Check:

   Strong SECRET_KEY = A [OK]

Hint: Never share SECRET_KEY; generate a strong random one [OK]

Common Mistakes:

• Using default insecure keys
• Removing SECRET_KEY setting
• Ignoring warnings thinking they're only for dev

5. You want to ensure your Django app is secure for production. Which combination of settings should you verify or enable after running manage.py check --deploy?

hard

A. Remove ALLOWED_HOSTS, set DEBUG=True, and disable security middleware

B. Set SECURE_SSL_REDIRECT=True, SESSION_COOKIE_SECURE=True, and DEBUG=False

C. Set DEBUG=True, ALLOWED_HOSTS=['*'], and CSRF_COOKIE_SECURE=False

D. Keep DEBUG=True, set SECURE_HSTS_SECONDS=0, and disable SSL redirect

Solution

1. Step 1: Identify secure production settings

   SECURE_SSL_REDIRECT and SESSION_COOKIE_SECURE enforce HTTPS and secure cookies; DEBUG must be False in production.

2. Step 2: Eliminate insecure options

   Options with DEBUG=True or ALLOWED_HOSTS=['*'] are insecure and should be avoided.

3. Final Answer:

   Set SECURE_SSL_REDIRECT=True, SESSION_COOKIE_SECURE=True, and DEBUG=False -> Option B

4. Quick Check:

   Secure settings = C [OK]

Hint: Disable DEBUG and enable SSL redirect for production [OK]

Common Mistakes:

• Leaving DEBUG=True in production
• Allowing all hosts with ALLOWED_HOSTS=['*']
• Disabling security middleware