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
用防火墙限制对缓存系统和数据库的访问