此文档是对 Django 安全特性的概述。包含保障那些用 Django 建立的网站的安全性建议。
\n\nThe golden rule of web application security is to never trust user-controlled\ndata. Hence, all user input should be sanitized before being used in your\napplication. See the forms documentation for\ndetails on validating user inputs in Django.
\nIn a cross-site scripting attack, malicious code in the form of a client-side\nscript is injected into another user's web browser, where it will be executed.
\nThis is typically done by:
\nstoring the malicious script in the database where it will be retrieved and\npresented to other users in their browsers, or
getting users to click a link which will cause the attacker's JavaScript to\nbe executed by the user's browser.
Cross-site scripting attacks can originate from any untrusted source of data,\nincluding cookies or web services, if the data are not adequately sanitized\nbefore being published in a page.
\nDjango templates provide protection against the majority of cross-site\nscripting attacks by automatically escaping characters that represent a\nrisk (that is, HTML characters that could be\ninterpreted by the browser to malicious effect are instead safely\ndisplayed).
\nHowever, the extent of this protection and its limitations should be\nunderstood.
\nAmbiguity between the developer's intention and how the browser interprets\nHTML can expose the client to unintended code execution. Suppose that a\ndeveloper creates:
\n<style class={{ var }}>...</style>\nwhere var is expected to contain something like 'class1'. If var\nwere set to 'class1 onmouseover=javascript:func()' though, this could\nresult in unauthorized JavaScript execution due to differences in how browsers\nwill interpret this imperfect HTML.
Explicit template design, in which the quotes are not left to the variable to\nprovide:
\n<style class="{{ var }}">...</style>\nwould eliminate this possibility.
\nIt is also important to be particularly careful when using the is_safe\nattribute with custom template tags, the safe template tag,\nmark_safe, and when autoescape is turned off.
Django's built-in escaping is intended to protect HTML output. If you are using\nthe template system to output something other than HTML, the characters and\nstrings that require escaping might be entirely different.
\nAdditionally, be very careful when storing HTML in the database, especially\nwhen that HTML is retrieved and displayed. Unless the HTML is guaranteed to\ncome from a trusted source - user input is not a trusted source - stored HTML\nshould be checked and sanitized, preferably on input as well as output.
\n发起 CSRF 攻击的人可以使用其他用户的证书执行操作，且是在其不知情或不同意的情况下。
\nDjango 内置了保护措施来防御大多数 CSRF 攻击，您需要在合适的地方 授权并使用它 。但和多数缓解性技术一样，它是有局限性的。比如可以全局禁用 CSRF 模块或者特定的视图。请三思而后行。如果您的网页还有脱离您控制的子域，还将会有其他 限制 。
\nCSRF protection works by checking for a secret in each\nPOST request. This ensures that a malicious user cannot "replay" a form POST to\nyour website and have another logged-in user unwittingly submit that form. The\nmalicious user would have to know the secret, which is user specific (using a\ncookie).
\n在部署 HTTPS 时，CsrfViewMiddleware 会检查 HTTP 报文的 referer 首部是否设置为同源的 URL（包括子域和端口）。因为 HTTPS 提供了额外的安全性，所有通过转发不安全连接请求并在支持的浏览器中使用 HSTS 来确保连接在可用的地方使用了 HTTPS ，这一点是很重要的。
除非绝对需要，否则对视图进行标记 csrf_exempt 装饰器时要极其慎重。
SQL 注入能让恶意用户能在数据库中执行任意 SQL 代码。这将导致记录被删除或泄露。
\nDjango 的 querysets 在被参数化查询构建出来时就被保护而免于 SQL 注入。查询的 SQL 代码与查询的参数是分开定义的。参数可能来自用户从而不安全，因此它们由底层数据库引擎进行转义。
\nDjango 也为开发者提供了书写 原始查询 或执行 自定义 sql 的权力。应当尽可能少地使用这些方法，并且您应该小心并准确地转义一切用户可控的参数。另外，在使用 extra() 和 RawSQL 时应当小心谨慎。
访问劫持能让恶意网页覆盖另一个网页。可能会有毫不知情的用户被骗入目标网页并执行意料之外的操作。
\nDjango 包含 访问劫持保护 ，以 X-Frame-Options middleware 的形式在支持它的浏览器中阻止一个网页被渲染在 frame 的内部。可在每个视图的基础上禁用保护，也可配置发送的确切头部值。
对于任何不会被第三方网站嵌入 frame 的网页，或者只允许使用一小部分的网页来说，强烈建议使用中间件。
\n通过 HTTPS 部署您的网页是保障安全的最佳办法。没有它，恶意用户就可以在客户端和服务器之间嗅探验证资格或其他信息，在某些情况下 -- 比如 主动 网络攻击者 -- 会修改发送中的数据。
\n如果您想得到 HTTPS 的保护，且已经在您的服务器上启用了，下面还有一些额外的步骤需要执行：
\n如有必要，设置 SECURE_PROXY_SSL_HEADER，确保您已经彻底的了解了它的警告提示。如果不这么做，将会导致 CSRF 漏洞，如果操作不正确，也是非常危险的。
设置 SECURE_SSL_REDIRECT 为 True，这样 HTTP 的请求就会被重定向到 HTTPS。
请注意 SECURE_PROXY_SSL_HEADER 下的注意事项。对于反向代理的情况，配置主 Web 服务器来做重定向到 HTTPS 可能更容易或更安全。
使用 'secure' cookies。
\n如果浏览器使用默认的 HTTP 来实现初始连接，可能会导致已有的 cookies 泄露。因此，您应当将 CSRF_COOKIE_SECURE 和 CSRF_COOKIE_SECURE 设置为 True。这样浏览器就会仅用 HTTPS 连接来发送 cookies。注意，这会使得 sessions 不能再通过 HTTP 工作，且 CSRF 防御机制将会阻止任何通过 HTTP 接收到的 POST 数据（当然把所有 HTTP 都弄成 HTTPS 是最好的）。
使用 HTTP 严格传输安全 （HSTS）
\nHSTS 是一个 HTTP 标头，它通知浏览器，所有未来连接到一个特定的网站应该始终使用 HTTPS。结合重定向 HTTP 请求到 HTTPS，这将确保连接总是享受 SSL 的额外安全，只要有一个成功的连接发生。HSTS 可以通过 SECURE_HSTS_SECONDS、 SECURE_HSTS_INCLUDE_SUBDOMAINS 和 SECURE_HSTS_PRELOAD 来配置，或者在网络服务器上配置。
Django uses the Host header provided by the client to construct URLs in\ncertain cases. While these values are sanitized to prevent cross-site scripting\nattacks, a fake Host value can be used for cross-site request forgery,\ncache poisoning attacks, and poisoning links in emails.
Because even seemingly-secure web server configurations are susceptible to fake\nHost headers, Django validates Host headers against the\nALLOWED_HOSTS setting in the\ndjango.http.HttpRequest.get_host() method.
This validation only applies via get_host();\nif your code accesses the Host header directly from request.META you\nare bypassing this security protection.
更多细节请参照完整的 ALLOWED_HOSTS 文档。
另外，如果您的配置需要，Django 要求您明确启用对 X-Forwarded-Host 标头的支持（通过 USE_X_FORWARDED_HOST 配置）。
浏览器使用 Referer 头部来把关于用户是如何到达那里的信息发送到网站。通过设置 Referrer 策略，限制在哪些情况下设置 Referer 头部，可以保护您用户的隐私。请看 安全中间件参考中的 referrer 策略部分 了解更多细节。
跨源弹出式窗口策略（COOP）头允许浏览器将一个顶级窗口与其他文档隔离，把它们放在不同的上下文组中，使它们不能直接与顶级窗口交互。如果一个受 COOP 保护的文档打开了一个跨源弹出窗口，该弹出窗口的 window.opener 属性将为 null。COOP 可以防止跨源攻击。详情请看 安全中间件参考资料中的跨源弹出式窗口策略部分。
Cross-Origin Resource Sharing (CORS) controls which origins are permitted to\naccess resources from your site via the browser. Django does not include\nbuilt-in support for CORS headers.
\n\n类似于 CSRF 限制 要求一个被部署的网页应让不受信任的用户不能访问任何子域，django.contrib.sessions 也有限制。参照 会话主题指南中关于安全的部分 获取更多细节。
If your site accepts file uploads, it is strongly advised that you limit\nthese uploads in your web server configuration to a reasonable\nsize in order to prevent denial of service (DOS) attacks. In Apache, this\ncan be easily set using the LimitRequestBody directive. You should not rely\nsolely on DATA_UPLOAD_MAX_MEMORY_SIZE\nnor FILE_UPLOAD_MAX_MEMORY_SIZE.
如果您为自己的静态文件提供服务，确保像 Apache 的 mod_php 这种能把静态文件当作代码来执行的处理程序已经关闭。您绝不会希望用户能够通过上传并请求特制文件来执行任意的代码。
如果媒体文件没有遵循安全性最佳惯例，Django 的媒体上传处理会产生一些漏洞。特别的，如果一个 HTML 文件包含合法的 PNG 格式头部并附加一些恶意的 HTML，它是可以作为一个图片文件上传的。该文件将会通过 Django 用于 ImageField 图片处理（Pillow）库的验证。当此文件随后被展示给用户时，它可以被显示为 HTML，这取决于您的服务器类型于配置。
在框架级别上没有防护技术方案可以安全地验证所有用户上传的文件内容，但是您可以采取其他步骤来减轻这些攻击：
\n通过一直为来自不同顶级域名或二级域名的用户提供上传内容可以防御一类的攻击。这可以防止被 same-origin policy 保护机制阻止的任何攻击，比如跨站脚本攻击。例如您的网站是 example.com，您应当通过形如 usercontent-example.com 的方式来提供上传内容服务（配置 MEDIA_URL）。仅仅从像 usercontent.example.com 这样的子域提供内容是*不够*的。
除此之外，应用可以选择定义一个列表来限制允许用户上传的文件的扩展名，并将 Web 服务器配置为仅为此类文件服务。
Form submissions containing files are not limited by\nDATA_UPLOAD_MAX_MEMORY_SIZE. Under ASGI, the entire request may be\nspooled to disk before any file size validation is performed. It is strongly\nadvised that you limit the maximum request body size in your web server\nconfiguration to prevent denial of service (DOS) attacks.
Content Security Policy (CSP) is a browser security mechanism that helps\nprotect web applications against attacks such as cross-site scripting (XSS) and\nother content injection attacks.
\nCSP allows web applications to define which sources of content are trusted,\ninstructing the browser to load, execute, or render resources only from those\nsources. This effectively creates an allowlist of content origins, reducing the\nrisk of malicious code execution.
\nKey benefits of enabling CSP include:
\nMitigating XSS attacks by blocking inline scripts and restricting external\nscript loading.
Controlling which external resources (e.g., images, fonts, stylesheets) can\nbe loaded.
Preventing unwanted framing of your site to protect against clickjacking.
Reporting violations to a specified endpoint, enabling monitoring and\ndebugging.
For configuration instructions, see the Using CSP\ndocumentation, and refer to the CSP overview for details\non directives and settings.
\nWhile CSP is a powerful security mechanism, it's important to understand its\nlimitations and implications, particularly when used in Django:
\nPolicy exclusion risks: Avoid excluding specific paths or responses from\nCSP protection. Due to the browser’s same-origin policy, a vulnerability on\nan unprotected page (e.g., one allowing arbitrary script injection) may be\nleveraged to attack protected pages. Excluding any route can significantly\nweaken the site's overall CSP protection.
Performance overhead: Although typically negligible, CSP adds some processing\noverhead. Nonce generation involves secure randomness for each applicable\nrequest. For high-traffic applications or resource-constrained environments,\nmeasure the performance impact accordingly.
Browser support: While CSP Levels 1 and 2 are widely supported, newer\ndirectives (CSP Level 3+) or complex policy behaviors may vary across\nbrowsers. Test your policy across the environments you intend to support.
Despite these limitations, CSP remains an important and recommended security\nlayer for web applications. Understanding its constraints will help you design\na more effective and reliable deployment.
\n虽然 Django 开箱即提供了良好的安全保护，但正确部署你的应用程序并利用网络服务器、操作系统和其他组件的安全保护仍然很重要。
\n确保你的 Python 代码是在网络服务器的根目录之外。这将确保你的 Python 代码不会被意外地作为纯文本提供（或意外地执行）。
小心一切 用户上传的文件。
Django 不会对认证用户的请求进行节流。为了防止针对认证系统的暴力攻击，你可以考虑部署一个 Django 插件或网络服务器模块来节制这些请求。
保持您的 SECRET_KEY，以及如果正在使用的话，SECRET_KEY_FALLBACKS 保持保密。
用防火墙限制缓存系统和数据库的可访问性是个好主意。
看一下开源 Web 应用安全计划（OWASP） Top 10 list ，它指定了网络应用程序中一些常见的漏洞。尽管 Django 拥有解决某些问题的工具，但在项目设计中必须考虑其他问题。
Mozilla 讨论了很多与 web security 相关的主题。他们的网页还包括适用于任何系统的安全原则。