• 应用安全

本文是 OWASP Cheat Sheet Series 中《Django Security Cheat Sheet》的深度解读与实践指南，面向使用 Django 框架构建 Web 应用的开发者。文章以 Django 内置的安全特性（secure-by-default）为主线，逐项讲解认证、密钥管理、安全响应头、CSRF/XSS 防护、HTTPS 强制与部署前安全检查等配置要点，结合本仓库 Password Storage Cheat Sheet、Cross-Site Request Forgery Prevention Cheat Sheet 等关联文档补充底层原理，读完后你将掌握一套可直接复制到settings.py与视图代码中的 Django 安全加固方案。

总体建议（General Recommendations）

Django 自带许多开箱即用的安全特性，默认倾向于安全（secure-by-default），但这些特性足够灵活，开发者在不熟悉内部机制时也可能配置出不安全的组合。本速查表的目标正是枚举这些易错场景。在深入各项配置前，先遵循三条底线：

• 保持依赖更新：始终将 Django 及应用依赖升级到最新版本，以跟进安全漏洞修复。可参考仓库中 Django REST Framework Cheat Sheet 关于依赖更新流程的建议：定期（每月/每季度）例行更新、每周评估重要安全漏洞、在极端情况下执行紧急更新。
• 生产环境严禁开启调试：切勿在生产环境中设置DEBUG = True，这既会泄露堆栈信息，也会触发check --deploy的security.W018警告。
• 防护暴力破解：使用django-ratelimit、django-axes等第三方包限制登录尝试次数，防止针对认证接口的暴力破解。

认证加固（Authentication）

启用官方认证应用

使用django.contrib.auth应用提供登录、登出、密码修改等视图与表单。在settings.py的INSTALLED_APPS中同时加入其依赖模块django.contrib.contenttypes与django.contrib.sessions：

INSTALLED_APPS = [ # ... 'django.contrib.auth', 'django.contrib.contenttypes', 'django.contrib.sessions', # ... ]

用装饰器强制登录

@login_required装饰器确保只有已认证用户能访问目标视图；未认证用户会被重定向到登录页。默认重定向到登录页，也可通过login_url指定自定义地址：

from django.contrib.auth.decorators import login_required # 未认证用户被重定向到默认登录页 @login_required def my_view(request): # Your view logic # 未认证用户被重定向到自定义 '/login-page/' @login_required(login_url='/login-page/') def my_view(request): # Your view logic

配置密码策略校验器

通过AUTH_PASSWORD_VALIDATORS强制密码策略。Django 提供四类内置校验器，可组合使用并配置选项：

AUTH_PASSWORD_VALIDATORS = [ { # 检查密码与用户属性（如用户名、邮箱）的相似度 'NAME': 'django.contrib.auth.password_validation.UserAttributeSimilarityValidator', 'OPTIONS': { 'user_attributes': ('username', 'email', 'first_name', 'last_name'), 'max_similarity': 0.7, } }, { # 检查密码是否满足最小长度 'NAME': 'django.contrib.auth.password_validation.MinimumLengthValidator', 'OPTIONS': { 'min_length': 8, } }, { # 检查密码是否出现在常见弱密码列表中 'NAME': 'django.contrib.auth.password_validation.CommonPasswordValidator', }, { # 检查密码是否完全由数字组成 'NAME': 'django.contrib.auth.password_validation.NumericPasswordValidator', } ]

密码哈希与校验工具函数

永远不要明文存储密码。Django 提供两个底层工具函数：

• make_password()：将明文密码哈希化后存储。
• check_password()：将用户输入的明文密码与库中哈希值比对。

from django.contrib.auth.hashers import make_password #... hashed_pwd = make_password('plaintext_password')

from django.contrib.auth.hashers import check_password #... plain_pwd = 'plaintext_password' hashed_pwd = 'hashed_password_from_database' if check_password(plain_pwd, hashed_pwd): print("The password is correct.") else: print("The password is incorrect.")

底层原理（哈希算法选型）：本仓库的 Password Storage Cheat Sheet 明确指出，密码必须使用慢速、可加盐的哈希算法（如 Argon2id、bcrypt、PBKDF2）存储，而 SHA-256 这类快速哈希因便于暴力破解而不适用。Django 默认使用 PBKDF2 算法，若追求更强的内存困难型算法，可配置PASSWORD_HASHERS优先使用 Argon2id（建议至少 19 MiB 内存、2 次迭代、1 并行度）。该文档还提醒：当 PBKDF2 处理超过哈希函数块大小（SHA-256 为 64 字节）的长密码时，若实现不当可能引发拒绝服务（Django 2013 年曾因此发布安全公告），因此对超长密码需谨慎处理。

密钥管理（Key Management）

SECRET_KEY用于 Django 的加密签名（会话、密码重置令牌、CSRF 等均依赖它），必须严格保密。建议：

• 生成至少 50 字符、包含字母、数字与符号混合的随机密钥；
• 使用强随机生成器生成，例如 Django 提供的get_random_secret_key()函数；
• 避免在settings.py或其他代码位置硬编码密钥，应存入环境变量或密钥管理服务：

import os SECRET_KEY = os.environ.get('DJANGO_SECRET_KEY')

• 定期轮换密钥，但注意轮换会使既有会话、密码重置令牌等失效；一旦密钥泄露必须立即轮换。

check --deploy会通过security.W009警告检查密钥是否过短（少于 50 字符）、唯一字符过少或带有django-insecure-前缀（Django 自动生成密钥的标志）。

安全响应头（Headers）

在settings.py的MIDDLEWARE中加入django.middleware.security.SecurityMiddleware，其为响应添加多项安全相关参数：

• SECURE_CONTENT_TYPE_NOSNIFF：设为True，通过X-Content-Type-Options: nosniff响应头防止 MIME 类型嗅探攻击；
• SECURE_HSTS_SECONDS：配合 HSTS（HTTP 严格传输安全）确保站点仅通过 HTTPS 访问。

同时加入django.middleware.clickjacking.XFrameOptionsMiddleware（注意顺序：必须排在SecurityMiddleware之后，中间件顺序很重要），用于设置：

• X_FRAME_OPTIONS：设为'DENY'或'SAMEORIGIN'，为所有 HTTP 响应添加X-Frame-Options响应头，防护点击劫持（Clickjacking）攻击。

点击劫持防护的更多细节可参考仓库中的 Clickjacking Defense Cheat Sheet。

内容安全策略（Content Security Policy，CSP）

Django 默认不内置 CSP 支持。可以通过两类方式实现：

• 引入第三方库（如django-csp）配置 CSP 中间件与策略；
• 直接在 HTTP 响应头中配置 CSP 策略。

CSP 策略的完整设计（default-src、script-src、object-src等指令的取舍）可参考仓库中的 Content Security Policy Cheat Sheet，该文档给出了系统化的 CSP 策略编写建议，避免"形同虚设"的策略。

Cookie 安全（Cookies）

以下三个设置点确保 Cookie 只通过 HTTPS 传输：

• SESSION_COOKIE_SECURE = True：会话 Cookie 仅通过安全（HTTPS）连接发送；
• CSRF_COOKIE_SECURE = True：CSRF Cookie 仅通过安全连接发送；
• 在视图中通过HttpResponse.set_cookie()设置自定义 Cookie 时，必须将secure参数设为True：

response = HttpResponse("Some response") response.set_cookie('my_cookie', 'cookie_value', secure=True)

跨站请求伪造防护（CSRF）

在MIDDLEWARE中加入django.middleware.csrf.CsrfViewMiddleware，为响应添加 CSRF 相关保护。表单中使用{% csrf_token %}模板标签嵌入 CSRF 令牌：

<form method="post"> {% csrf_token %} <!-- Your form fields here --> </form>

对于 AJAX 调用，需要在请求发起前先提取 CSRF 令牌。仓库的 Cross-Site Request Forgery Prevention Cheat Sheet 详细记录了 Django 的令牌交换机制：Django 使用请求头X-CSRFToken（区别于 Rails、Laravel 使用的X-CSRF-Token），典型做法是先读取页面 meta 标签或 Cookie 中的令牌，再通过XMLHttpRequest.setRequestHeader("X-CSRFToken", csrf_token)附加到每次请求，该文档还提供了 axios 等库的全局拦截器配置示例。

跨站脚本防护（XSS）

在模板渲染层面，遵循以下建议：

• 使用 Django 内置模板系统渲染模板，依赖其自动 HTML 转义（Automatic HTML escaping）机制对输出进行转义；
• 尽量避免使用safe过滤器或mark_safe函数关闭自动转义；确需使用时，必须确保输入来自可信来源，对用户可控输入要格外谨慎；
• 需要向模板中的 JavaScript 传递数据时，使用json_script模板过滤器安全地序列化数据；
• Django 自带针对 HTML、JavaScript 等上下文的基础 XSS 防护，但应用层仍应遵循仓库中 Cross Site Scripting Prevention Cheat Sheet 与 DOM based XSS Prevention Cheat Sheet 提供的输出编码与上下文感知转义规则。

HTTPS 强制（HTTPS）

• 确保django.middleware.security.SecurityMiddleware已在MIDDLEWARE中（未添加则补上）；
• 设置SECURE_SSL_REDIRECT = True：自动将所有 HTTP 请求 301 永久重定向到 HTTPS（浏览器会记住该重定向，后续请求直接走 HTTPS）；
• 若应用位于代理或负载均衡之后，设置SECURE_PROXY_SSL_HEADER，让 Django 能识别原始请求的协议（否则可能因代理转发的 HTTP 请求被误判为 HTTPS 而绕过重定向）。

管理后台 URL 混淆（Admin panel URL）

默认管理后台地址为example.com/admin/，可修改默认 URL 以小幅提高自动化攻击的难度。操作方法：在项目的默认应用文件夹中找到管理顶层 URL 的urls.py，修改urlpatterns列表中指向admin.site.urls的路径，使其不再是"admin/"。这通过隐藏常见的后台端点增加一层额外防护（注意：这属于"隐匿"型措施，不能替代认证、授权等核心控制，相关纵深防御思路可参考仓库的 Access Control Cheat Sheet）。

部署前安全检查：内置命令check --deploy

Django 提供内置安全检查命令manage.py check --deploy，会在部署模式下扫描安全相关设置并输出警告：

$ ./manage.py check --deploy System check identified some issues: WARNINGS: ?: (security.W004) You have not set a value for the SECURE_HSTS_SECONDS setting. If your entire site is served only over SSL, you may want to consider setting a value and enabling HTTP Strict Transport Security. Be sure to read the documentation first; enabling HSTS carelessly can cause serious, irreversible problems. ?: (security.W008) Your SECURE_SSL_REDIRECT setting is not set to True. Unless your site should be available over both SSL and non-SSL connections, you may want to either set this setting True or configure a load balancer or reverse-proxy server to redirect all connections to HTTPS. ?: (security.W009) Your SECRET_KEY has less than 50 characters, less than 5 unique characters, or it's prefixed with 'django-insecure-' indicating that it was generated automatically by Django. Please generate a long and random value, otherwise many of Django's security-critical features will be vulnerable to attack. ?: (security.W012) SESSION_COOKIE_SECURE is not set to True. Using a secure-only session cookie makes it more difficult for network traffic sniffers to hijack user sessions. ?: (security.W016) You have 'django.middleware.csrf.CsrfViewMiddleware' in your MIDDLEWARE, but you have not set CSRF_COOKIE_SECURE to True. Using a secure-only CSRF cookie makes it more difficult for network traffic sniffers to steal the CSRF token. ?: (security.W018) You should not have DEBUG set to True in deployment. ?: (security.W020) ALLOWED_HOSTS must not be empty in deployment. System check identified 7 issues (0 silenced).

对照上文逐项修正这些警告即可完成基础加固。例如：W020要求在生产环境显式配置ALLOWED_HOSTS（空值会触发该警告）；W004提示若全站仅走 SSL 可启用 HSTS（注意需先理解后果，HSTS 配置不当会造成不可逆问题）；W016提示已启用 CSRF 中间件但未设置CSRF_COOKIE_SECURE。此命令可作为 CI/CD 流水线中的自动化安全门禁，与本仓库的 CI/CD Security Cheat Sheet 相结合，实现"可重复的加固流程"。

参考与延伸阅读

本仓库相关的进一步资料：

• Django REST Framework Cheat Sheet：DRF API 场景下的认证类、权限类、限流与分页等安全配置；
• Cross-Site Request Forgery Prevention Cheat Sheet：含 DjangoX-CSRFToken请求头的 AJAX 集成示例；
• Password Storage Cheat Sheet：Argon2id、bcrypt、PBKDF2 的选型与参数建议，用于优化 Django 默认哈希配置；
• Content Security Policy Cheat Sheet：CSP 策略的系统化编写指南；
• Clickjacking Defense Cheat Sheet：X-Frame-Options与 frame-ancestors 的完整对比；
• Cross Site Scripting Prevention Cheat Sheet 与 DOM based XSS Prevention Cheat Sheet：XSS 上下文感知编码细则。

• 应用安全