対象：Djangoでアプリを運営している人。ここでは攻撃手順は扱わず、安全な既定を活かしつつ、設定で開く穴を塞ぐ方法を解説します。全体像は フレームワーク別セキュリティの入口 も参照。
三大落とし穴（設定で開く）
Djangoの既定は優秀ですが、次の3つは設定と作り込みで守る領域です。
① 本番の DEBUG=True
エラー画面に設定・環境変数・秘密が露出。故意のエラーで抜かれる。
② SECRET_KEY の漏えい
署名・セッション・CSRFの土台。漏れると偽造・改ざんの恐れ。
③ 認可の不足
認証はあるが権限/所有者チェック漏れ。ID差し替えで他人のデータ。
そのほか、raw()/extra() や文字列連結によるSQLi、pickle 等の安全でないデシリアライズ、ALLOWED_HOSTS 未設定、依存(pip)の既知CVE放置も注意点です。
塞ぎ方（3ステップ）
本番は DEBUG=False ＋ ALLOWED_HOSTS
ALLOWED_HOSTSを正しく設定。詳細エラーの外部露出を止め、静的/メディア配信も本番向けに。デプロイ手順に組み込み毎回確認する。SECRET_KEY を環境から・非公開に
SECRET_KEYはコード/リポジトリに書かず環境変数や秘密管理から読み込む。公開ディレクトリやDEBUG画面から露出させない。万一漏れたら速やかにローテーション（→ 公開ディレクトリに秘密を置かない）。認可を明示し、危険な入力経路を断つ
raw() の文字列連結を避け、信頼できないデータをpickleで復元しない。依存(pip)はCVE監視＋即パッチ（→ IDORとは）。やりがち（危険）
- 本番を
DEBUG=Trueのまま SECRET_KEYをコード/リポジトリに直書き- 認可を書かず「ログイン＝閲覧可」
raw()の文字列連結・pickleで復元
正しい
- 本番 DEBUG=False＋ALLOWED_HOSTS
SECRET_KEYは環境から・非公開- 認可を明示（権限/所有者スコープ）
- ORM/プレースホルダ・信頼できない復元を避ける
当サイトの視点：バッテリー同梱でも『設定と認可』は自分の責任
Djangoは多くを既定で守ってくれますが、本番の設定（DEBUG/SECRET_KEY/ALLOWED_HOSTS）と認可だけは、環境ごと・アプリごとに自分で正しく決める必要があります。当サイトが繰り返し見る事故も、凝った攻撃より「本番でデバッグが開いていた」「秘密が露出していた」「認可が無かった」という設定・運用の型が中心。だから守りの重心は、本番設定を締め、秘密を非公開に保ち、認可を明示すること。堅い既定を台無しにしないことが、Django運用の要点です。
次に読む
- 入口：フレームワーク別セキュリティ（入口） ／ Laravelのセキュリティ対策（本番DEBUG・秘密露出が近い）
- 秘密：公開ディレクトリに秘密を置かない ／ 実務：脆弱性(CVE)対応の実務
- 用語：IDORとは ／ SQLインジェクションとは
よくある質問
QDjangoは安全なフレームワークですか？
Djangoは『バッテリー同梱』の思想で、ORMによるSQL対策、CSRF保護、テンプレートの自動エスケープ、認証基盤などを標準で備えます。正しく設定すれば堅いフレームワークですが、事故は本体でなく設定で起きます。とくに本番のDEBUG=True、SECRET_KEYの漏えい、認可の作り込み不足は、Django特有というより運用・設定の問題として繰り返し起きます。
Q本番で DEBUG=True のままだと何が危険ですか？
DEBUGが有効だと、エラー画面に設定値・環境変数・スタックトレースなど内部情報が詳しく表示され得ます。攻撃者はわざとエラーを起こして情報を引き出せます。本番では必ず DEBUG=False にし、ALLOWED_HOSTS を正しく設定してください。あわせて詳細エラーの外部露出を止め、静的/メディアの配信設定も本番向けに見直します。
QSECRET_KEY はなぜ重要ですか？
SECRET_KEY は署名付きCookieやセッション、CSRFトークン、パスワードリセットなどの土台になる鍵です。漏えいすると、これらの偽造や改ざんに繋がり得ます。SECRET_KEY はコードやリポジトリに書かず、環境変数や秘密管理から読み込み、万一漏れたら速やかにローテーションしてください。公開ディレクトリやDEBUG画面から露出させないことも重要です。