python-django-web-server-security

# Django (Python) Web 安全规范 (Django 6.0.x, Python 3.x) 本文档旨在作为一份**安全规范**，支持： 1. **默认安全的代码生成**：用于新的 Django 代码。 2. **安全审查/漏洞挖掘**：针对现有 Django 代码（被动式“工作时发现问题”和主动式“扫描仓库并报告发现”）。 本文档特意编写为一系列**规范性要求**（“必须/应该/可以”）以及**审计规则**（不良模式是什么样、如何检测它们、以及如何修复/缓解它们）。 --- ## 0) 安全性、边界和防滥用约束（必须遵守） * 禁止请求、输出、记录或提交机密信息（API 密钥、密码、私钥、会话 Cookie、`SECRET_KEY`、`SECRET_KEY_FALLBACKS`、数据库密码）。 * 禁止通过禁用保护措施来“修复”安全性（例如，移除 `CsrfViewMiddleware`，到处使用 `@csrf_exempt`，将 `ALLOWED_HOSTS` 放宽为 `['*']`，禁用 `SecurityMiddleware`，禁用模板自动转义，禁用权限检查）。 * 必须在审计期间提供**基于证据的发现**：引用文件路径、代码片段和证明该声明的具体配置值。 * 必须诚实地对待不确定性：如果基础设施（反向代理、WAF、CDN、入口控制器）中可能存在保护措施，请将其报告为“在应用代码中不可见；在运行时/边缘配置处验证”。 * 必须保持修复与 Django 预期的安全模型兼容：尽可能优先使用 Django 的内置功能（中间件、身份验证、表单、ORM）而不是自定义安全逻辑。Django 的部署清单和系统检查是预期模型的一部分。([Django Project][1]) --- ## 1) 操作模式 ### 1.1 生成模式（默认） 当被要求编写新的 Django 代码或修改现有代码时： * 必须遵循本规范中的每一项**必须**要求。 * 应该遵循每一项**应该**要求，除非用户明确表示否则。 * 必须优先使用默认安全的 Django API 和经过验证的库，而不是自定义安全代码。 * 必须避免引入新的风险汇点（来自不受信任字符串的动态模板渲染、不安全的重定向、不安全的文件服务、Shell 执行、原始 SQL 字符串格式化、来自不受信任输入的具备 SSRF 能力的 URL 获取器）。 ### 1.2 被动审查模式（编辑时始终开启） 在 Django 仓库的任何地方工作时（即使用户没有要求进行安全扫描）： * 必须“注意到”所触及/附近代码中违反本规范的行为。 * 应该在问题出现时提及，并提供简要的