此文档是对 Django 安全特性的概述。包含保障那些用 Django 建立的网站的安全性建议。
XSS attacks allow a user to inject client side scripts into the browsers of other users. This is usually achieved by storing the malicious scripts in the database where it will be retrieved and displayed to other users, or by getting users to click a link which will cause the attacker's JavaScript to be executed by the user's browser. However, XSS attacks can originate from any untrusted source of data, such as cookies or web services, whenever the data is not sufficiently sanitized before including in a page.
Django 模板可以保护您免受大多数 XSS 攻击。但是了解它提供了怎样的保护，以及有什么限制是很重要的。
对于 HTML 来说，Django 模板中的 转义特殊字符 是尤其危险的。虽然它保护用户免受大多数恶意输入的攻击，但并非万无一失。比如，出现下面这种情况就会保护失效：
<style class={{ var }}>...</style>
如果 var 被设置为 'class1 onmouseover=javascript:func()' ，将导致未经授权的 JavaScript 脚本执行，这取决于浏览器如何渲染有缺陷的HTML。（引用属性值可以解决这个问题）
与此不相上下的还有在使用带有自定义模板标签的 is_safe ，safe 模板标签，mark_safe，以及关闭自动转义时要特别小心。
此外，如果使用模板系统输出了除 HTML 之外的内容，可能会有完全独立的字符和单词需要转义。
您在将 HTML 储存到数据库中时也要非常小心，特别是在检索和显示 HTML 的时候。
发起 CSRF 攻击的人可以使用其他用户的证书执行操作，且是在其不知情或不同意的情况下。
Django 内置了保护措施来防御大多数 CSRF 攻击，您需要在合适的地方 授权并使用它 。但和多数缓解性技术一样，它是有局限性的。比如可以全局禁用 CSRF 模块或者特定的视图。请三思而后行。如果您的网页还有脱离您控制的子域，还将会有其他 限制 。
CSRF 保护机制 通过检查每一个 POST 请求中的密文来实现。这保证恶意用户不能“复现”一个表单并用 POST 提交到你的网页，并让一个已登录用户无意中提交该表单。恶意用户必须知道特定于用户的密文（使用 cookie）。
在部署 HTTPS 时，CsrfViewMiddleware 会检查 HTTP 报文的 referer 首部是否设置为同源的 URL（包括子域和端口）。因为 HTTPS 提供了额外的安全性，所有通过转发不安全连接请求并在支持的浏览器中使用 HSTS 来确保连接在可用的地方使用了 HTTPS ，这一点是很重要的。
除非绝对需要，否则对视图进行标记 csrf_exempt 装饰器时要极其慎重。
SQL 注入能让恶意用户能在数据库中执行任意 SQL 代码。这将导致记录被删除或泄露。
Django 的 querysets 在被参数化查询构建出来时就被保护而免于 SQL 注入。查询的 SQL 代码与查询的参数是分开定义的。参数可能来自用户从而不安全，因此它们由底层数据库引擎进行转义。
Django 也为开发者提供了书写 原始查询 或执行 自定义 sql 的权力。应当尽可能少地使用这些方法，并且您应该小心并准确地转义一切用户可控的参数。另外，在使用 extra() 和 RawSQL 时应当小心谨慎。
访问劫持能让恶意网页覆盖另一个网页。可能会有毫不知情的用户被骗入目标网页并执行意料之外的操作。
Django 包含 访问劫持保护 ，以 X-Frame-Options middleware 的形式在支持它的浏览器中阻止一个网页被渲染在 frame 的内部。可在每个视图的基础上禁用保护，也可配置发送的确切头部值。
对于任何不会被第三方网站嵌入 frame 的网页，或者只允许使用一小部分的网页来说，强烈建议使用中间件。
通过 HTTPS 部署您的网页是保障安全的最佳办法。没有它，恶意用户就可以在客户端和服务器之间嗅探验证资格或其他信息，在某些情况下 -- 比如 主动 网络攻击者 -- 会修改发送中的数据。
如果您想得到 HTTPS 的保护，且已经在您的服务器上启用了，下面还有一些额外的步骤需要执行：
如有必要，设置 SECURE_PROXY_SSL_HEADER，确保您已经彻底的了解了它的警告提示。如果不这么做，将会导致 CSRF 漏洞，如果操作不正确，也是非常危险的。
设置 SECURE_SSL_REDIRECT 为 True，这样 HTTP 的请求就会被重定向到 HTTPS。
Please note the caveats under SECURE_PROXY_SSL_HEADER. For the
case of a reverse proxy, it may be easier or more secure to configure the
main web server to do the redirect to HTTPS.
使用 'secure' cookies。
如果浏览器使用默认的 HTTP 来实现初始连接，可能会导致已有的 cookies 泄露。因此，您应当将 CSRF_COOKIE_SECURE 和 CSRF_COOKIE_SECURE 设置为 True。这样浏览器就会仅用 HTTPS 连接来发送 cookies。注意，这会使得 sessions 不能再通过 HTTP 工作，且 CSRF 防御机制将会阻止任何通过 HTTP 接收到的 POST 数据（当然把所有 HTTP 都弄成 HTTPS 是最好的）。
使用 HTTP 严格传输安全 （HSTS）
HSTS is an HTTP header that informs a browser that all future connections
to a particular site should always use HTTPS. Combined with redirecting
requests over HTTP to HTTPS, this will ensure that connections always enjoy
the added security of SSL provided one successful connection has occurred.
HSTS may either be configured with SECURE_HSTS_SECONDS,
SECURE_HSTS_INCLUDE_SUBDOMAINS, and SECURE_HSTS_PRELOAD,
or on the web server.
在某些情况下，Django 使用客户端提供的 Host 头部来构造 URLs。这些值虽被清理以阻止跨站脚本攻击，但伪造 Host 值还是可以用于跨站请求伪造，缓存毒化攻击，以及电子邮件中的有毒链接。
因为即使看起来安全的服务器配置也容易受到假的 Host 头部信息的影响，Django 依靠定义在 django.http.HttpRequest.get_host() 方法中的 ALLOWED_HOSTS 来验证 Host 头部。
这些验证仅通过 get_host() 来实现；如果您的代码直接从 request.META 得到 Host 头部，您就绕过了这种安全保护机制。
更多细节请参照完整的 ALLOWED_HOSTS 文档。
警告
本文档的较早版本建议配置你的网络服务器，以确保它验证传入的 HTTP Host 头。虽然我们现在还是这样建议，但在许多常见 Web 服务器中，看似验证了 Host 头的配置，实际上却没有验证。例如，即使 Apache 的配置是让你的 Django 网站从一个非默认的虚拟主机上运行，并设置了 "ServerName"，HTTP 请求仍然有可能匹配这个虚拟主机，并提供一个假的 "Host " 头。因此，Django 现在要求你显式地设置 ALLOWED_HOSTS，而不是依赖 Web 服务器的配置。
另外，如果您的配置需要，Django 要求您明确启用对 X-Forwarded-Host 标头的支持（通过 USE_X_FORWARDED_HOST 配置）。
浏览器使用 Referer 头部来把关于用户是如何到达那里的信息发送到网站。通过设置 Referrer 策略，限制在哪些情况下设置 Referer 头部，可以保护您用户的隐私。请看 安全中间件参考中的 referrer 策略部分 了解更多细节。
The cross-origin opener policy (COOP) header allows browsers to isolate a
top-level window from other documents by putting them in a different context
group so that they cannot directly interact with the top-level window. If a
document protected by COOP opens a cross-origin popup window, the popup’s
window.opener property will be null. COOP protects against cross-origin
attacks. See the cross-origin opener policy section of the security
middleware reference for details.
类似于 CSRF 限制 要求一个被部署的网页应让不受信任的用户不能访问任何子域，django.contrib.sessions 也有限制。参照 the session topic guide section on security 获取更多细节。
注解
考虑从云服务或 CDN 提供静态文件服务来避免此类问题。
If your site accepts file uploads, it is strongly advised that you limit these uploads in your web server configuration to a reasonable size in order to prevent denial of service (DOS) attacks. In Apache, this can be easily set using the LimitRequestBody directive.
如果您为自己的静态文件提供服务，确保像 Apache 的 mod_php 这种能把静态文件当作代码来执行的处理程序已经关闭。您绝不会希望用户能够通过上传并请求特制文件来执行任意的代码。
如果媒体文件没有遵循安全性最佳惯例，Django 的媒体上传处理会产生一些漏洞。特别的，如果一个 HTML 文件包含合法的 PNG 格式头部并附加一些恶意的 HTML，它是可以作为一个图片文件上传的。该文件将会通过 Django 用于 ImageField 图片处理（Pillow）库的验证。当此文件随后被展示给用户时，它可以被显示为 HTML，这取决于您的服务器类型于配置。
在框架级别上没有防护技术方案可以安全地验证所有用户上传的文件内容，但是您可以采取其他步骤来减轻这些攻击：
example.com，您应当通过形如 usercontent-example.com 的方式来提供上传内容服务（配置 MEDIA_URL）。仅仅从像 usercontent.example.com 这样的子域提供内容是*不够*的。While Django provides good security protection out of the box, it is still important to properly deploy your application and take advantage of the security protection of the web server, operating system and other components.
SECRET_KEY。12月 13, 2021