xss 保護：
xss攻擊允許用戶注入客戶端腳本到其他用戶的服務器上。通常通過存儲惡意腳本到數據庫，其他用戶通過數據庫獲取惡意腳本，並在瀏覽器上呈現；或是使用戶點擊會引起攻擊者javascirpt腳本在用戶客戶端的連接來達到目的。但是xss攻擊可能發生在任意不可信的數據源頭，例如cookie和web service。無論何時，只要數據在頁面內沒有充分地消毒（sanitized），就可能發生xss攻擊。
用django的模板會保護你免受大部分xss攻擊，但理解模板提供什么保護，和其局限性是十分重要的。
django 模板的轉義對HTML危險的特殊字符。盡管這保護用戶受到大多數惡意輸入，但不是完全安全的。例如對下面的就不保護：
<styleclass={{var}}>...</style>
如果var被賦'class1onmouseover=javascript:func()'值，這會導致未授權的Javascript執行，取決於瀏覽器怎樣呈現未完成(imperfect)的HTML
當用到is_safe和自定義標簽一起時（using is_safe with custom template tags），格外小心十分重要。
另外，如果你用模板輸出非HTML的內容，完全分開的字符和單詞需要轉義。存儲HTML到數據庫時你同樣應該小心，尤其是HTML被加載並展示的。
CSRF保護：
CSRF 攻擊允許惡意用戶用未經另一個用戶知道或允許的證書執行動作。
django 內置了許多保護工作對抗大多數CSRF攻擊，假如你已經在合適的地方開啟並使用了。然而，像其他緩解技術一樣有局限性。例如，全局或為某些特定視圖禁止CSRF模塊是可能的。只有你明白你在做什么時才能這樣做。如果你的站點有在你控制范圍之外的子域名時同樣有其他限制。
CSRF保護的工作原理是檢測每個POST請求的隨機數。這確保了惡意用戶不能簡單地重放到你網站的表單的POST內容並讓其他已經登錄的用戶不知不覺地提交那個表單。惡意用戶需要知道那個隨機數，而這個隨機數是為特定用戶（用cookie）
當用HTTPS部署時，CsrfViewMiddleware將會檢查HTTP referer頭被設定到同源域的URL（包括子域和端口）。因為HTTPS提供額外的安全，所以在轉發不安全連接請求和可以用支持HSTS的瀏覽器的地方確保連接用HTTPS是很有必要的。
要非常小心地用csrf_exempt裝飾器修飾視圖，除非它絕對必要。
sql輸入保護：
sql注入是一種惡意用戶能夠在數據庫執行任意sql語句的攻擊。這會導致記錄被刪除或數據泄露。
用django的queryset，以數據庫驅動為基礎，合成的(resulting)sql會被合適地轉義。然而django同樣給開發者權利寫原始的查詢或自定義的sql。這些能力應該被保守地使用。你應該一直小心去適當轉義任何 用戶可以控制的參數。另外，當用extra()時你更應該小心謹慎（exercise caution）
點擊劫持保護：
點擊劫持是惡意站點包圍在另一個站點frame里的一種攻擊。這種攻擊能導致毫無戒心的用戶被騙在目標站點上執行意想不到的行為。
django在X-Frame-Options 中間件的表單里包含有點擊劫持保護功能，這種功能在支持的瀏覽器里可以保護站點不在frame里被渲染。可以按view的基礎禁用這個保護功能，或配置發送明確的header。
強烈推薦任何一個不必要或是只允許小部分 使頁面包裝在第三方frame的網站 使用這個中間件。
ssl/https:
出於安全考慮，把你的網站部署成HTTPS總是更好的，盡管並不是所有情況都適用。沒有HTTPS，惡意用戶會嗅探身份認證信息，或者其他在客戶端和服務器之間傳輸的信息。在某些案例中，活躍的攻擊者會改變任一方傳輸的數據。
如果你想在你的服務器上開啟HTTP，你需要做額外的步驟：
1、若必要，設置SECURE_PROXY_SSL_HEADER, 確保你徹底理解了警告。若不這樣做會導致CSRF漏洞，若沒有正確實施同樣會導致危險。
2、建立跳轉，基於HTTP的連接會跳轉到HTTPS。
用自定義的中間件可以做到這些。請注意SECURE_PROXY_SSL_HEADER的警告。對於反向跳轉的案例，配置主web 服務器做跳轉到HTTPS會更簡單和更安全
3、用安全的cookies
若瀏覽器用默認的HTTP連接，cookie會被泄露。所以需要你的 SESSION_COOKIE_SECURE 和CSRF_COOKIE_SECURE 設置為True。這會讓瀏覽器只通過HTTPS傳送cookies。注意着意味着session在HTTP下不會起作用，CSRF保護機制會阻止一切通過HTTP傳送的POST數據。
4、用 HSTS(HTTP Strict Transport Security)
HSTS是一個通知瀏覽器所有未來到某個站點的連接都用HTTPS的HTTP頭部。通過組合 對請求從HTTP到HTTPS的跳轉，確保了連接成功的連接總是能夠使用SSL提供的安全保障。HSTS通常被部署在服務器上。
主機頭確認
某些情況下，Django用客戶端提供的host頭來構建url。盡管這些值被過濾而組織XSS攻擊，虛假的host值可能被用來實施CSRF，緩存投毒攻擊，和郵件連接投毒。
因為看上去安全的服務器配置易受虛假host頭欺騙，Django會在HttpRequest.get_host()方法中確認host 頭是否與ALLOWED_HOSTS設置的值沖突。
確認只會由get_host()方法應用。若你的代碼通過request.META直接訪問host頭，你會繞過這個安全防護。
需要更多的信息請參考ALLOWED_HOSTS部分。
另外，1.3.1版本的Django要求你明確開啟對X-Forwarded-Host header的支持，如果你的配置需要的話
會話（session）安全：
和CSRF局限一樣，需要對站點特殊配置使得不信任的用戶沒有權限訪問子域，django.contrib.sessions同樣有局限。參考 session topic guide on security獲得更多信息。
用戶上傳內容：
若你的站點支持上傳，強烈建議你配置限制上傳文件的大小為合理的范圍來防止拒絕服務攻擊。在Apache下，用LimitRequestBody 指令很容易做到。
如果你自己管理你的靜態文件，一定要關閉像Apache的mod_php一樣的處理器，它們會把靜態文件當成代碼執行。你肯定不希望用戶通過上傳或請求精心制作的文件來執行任意代碼。
當媒體沒有遵循安全措施的最佳實踐時，django 的媒體文件上傳會造成某些漏洞。特別地，一個html文件會被當做文件上傳，如果文件包含一個png頭緊隨其后的惡意的html代碼。這個文件會通過django 的圖像處理庫的檢查。當這個文件隨后被展示給用戶，根據你服務器的類型和配置，會被呈現為html。
在框架層面沒有刀槍不入的驗證所有用戶上傳的技術性的解決方案存在。但是你可以通過一些步驟減少這種攻擊。
通過從一個獨特的頂級或二級域名 serve用戶上傳的文件可以防止一類攻擊。由於同源策略的保護，xss這類利用會被阻止。例如，你的站點在example.com上，你可以把用戶上傳的文件映射到usercontent-example.com。而映射到usercontent.example.com是不夠的。
應用還可以選擇定義一個白名單，允許用戶上傳特定的擴展名的文件。
額外的安全策略：
盡管django提供了好的開箱即用的安全保護措施。正確部署你的應用，並利用好服務器操作系統和其他組件的安全也十分必要
確保你的python代碼在服務器root文件夾之外，這確保了你的代碼不被錯誤地解釋為純文本（或錯誤地被執行）
小心用戶上傳的文件
django沒有限制用以認證用戶的請求。為防止暴力破解對認證系統的破壞，你可以考慮部署django的插件或web 服務器模塊來限制這些請求。
保密你的SECRET_KEY
用防火牆限制對緩存系統和數據庫的訪問