各框架對策
Django 的資安對策 — DEBUG、SECRET_KEY、授權的守法
Django 備有安全的預設，但事故來自設定：正式環境 DEBUG=True（設定／機密外洩）、SECRET_KEY 外洩，以及授權太薄。設 DEBUG=False、從環境變數載入 SECRET_KEY、把授權寫明確。以防禦視角講解，不含攻擊步驟。
對象：正在維運 Django 應用程式的人。這裡不談攻擊步驟，只講如何讓安全的預設持續生效，同時補起設定所開的破口。想看全貌，請參閱 各框架資安對策的入口。
三大陷阱（開在設定上）
Django 的預設很出色，但下面這三點是要在設定與程式碼裡去守的領域。
① 正式環境 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／機密外洩相近）
- 機密：別把機密資訊放進公開目錄 · 實務：漏洞應變實務手冊
- 名詞：IDOR 是什麼 · SQL 注入是什麼
FAQ
QDjango 是安全的框架嗎？
Django 奉行『電池內建』——基於 ORM 的 SQL 防護、CSRF 保護、樣板自動跳脫、認證系統都是標準配備。設定正確它是很穩固的框架，但事故不是來自核心，而是來自設定。正式環境 DEBUG=True、SECRET_KEY 外洩、授權太薄，與其說是 Django 特有的問題，不如說是反覆發生的維運／設定問題。
Q正式環境保留 DEBUG=True 有什麼危險？
DEBUG 開著時，錯誤頁面可能顯示詳細的內部資訊——設定值、環境變數、堆疊追蹤。攻擊者可以故意觸發錯誤把它們抽出來。正式環境務必設 DEBUG=False，並正確設定 ALLOWED_HOSTS。同時要停止把詳細錯誤顯示給外部，並檢視靜態／媒體檔的正式環境供應方式。
QSECRET_KEY 為什麼重要？
SECRET_KEY 是簽章 Cookie 與工作階段、CSRF token、密碼重設等機制底下的金鑰。一旦外洩，就可能導致對這些進行偽造或竄改。別把 SECRET_KEY 寫進程式碼或版本庫——從環境變數或機密管理載入，萬一外洩要立刻輪替。也要避免它透過公開目錄或 DEBUG 頁面被暴露。