การดำเนินการตามรายการตรวจสอบการนำไปใช้งาน

Django ships a built-in security auditor. The deployment checklist scans your settings and warns you about anything unsafe before launch day. ✅

Run the check command with the deploy flag. It activates extra security checks that normal checks skip, printing warnings you can act on.

Each warning has a code like security.W008 and a clear message. Use the code to look up exactly which setting to fix in the docs.

Point the checker at your production config, not your dev one. Set DJANGO_SETTINGS_MODULE so it audits the file that will actually run live.

If DEBUG is still True, the check shouts about it. A live site with DEBUG on leaks tracebacks and settings, so this is a hard stop.

The checklist warns when SESSION_COOKIE_SECURE or CSRF_COOKIE_SECURE is off, reminding you to keep auth cookies on HTTPS only.

A zero SECURE_HSTS_SECONDS or missing SSL redirect triggers warnings too. The check nudges you toward forcing encrypted connections everywhere.

A few warnings may not fit your setup. You can quiet specific ones with SILENCED_SYSTEM_CHECKS, but only after you truly understand each.

Treat warnings as errors in CI by adding --fail-level. Now a risky setting breaks the pipeline instead of slipping into production.

Run the checklist on every release, not just the first. New apps and settings can quietly reintroduce risks the audit will catch for you.

The deploy check is one layer. Run your tests and collectstatic in the same release step so code, assets, and security all get verified together.

Last question of the lesson, then a recap.

You learned to run check --deploy, read its warning codes, point it at prod settings, and even fail CI on risk. Audit every release and ship with confidence. 🚀