Python Web应用如何防范CSRF攻击_配置Django中间件防护-Python教程-PHP中文网

django csrf防护默认启用但需手动配合：表单加{% csrf_token %}、ajax传x-csrftoken头、注意samesite策略与https要求，否则403拒绝。

python web应用如何防范csrf攻击_配置django中间件防护

Django从1.2起默认启用django.middleware.csrf.CsrfViewMiddleware，但它只负责校验请求，不自动注入防护标记。你得在每个POST/PUT/DELETE表单里手动加{% csrf_token %}，否则浏览器发请求时没token，中间件直接403。

因为jQuery默认从Cookie读csrftoken并自动设请求头，fetch不会。Django的CSRF中间件检查两个地方：表单里的csrfmiddlewaretoken字段，或请求头中的X-CSRFToken。没设就拒绝。

Django Unfold

提供使用 django-unfold (v0.56+) 构建高级 Django 管理界面的专业指导。当用户提及 django-unfold、unfold admin 等内容时使用此技能。

下载

fetch需显式读取Cookie：document.cookie.match(/csrftoken=([^;]+)/)[1]，再传给headers: {'X-CSRFToken': token}
更稳妥的做法是把token存在<meta>标签里，比如<meta name="csrf-token" content="{{ csrf_token }}">，避免正则解析Cookie出错
注意SameSite=Lax的Cookie策略可能影响跨站请求下的token读取，开发环境建议检查浏览器开发者工具的Application → Cookies

中间件只拦截有CSRF敏感方法（POST/PUT/PATCH/DELETE）且带会话的请求。它不拦GET、HEAD、OPTIONS，也不拦没SessionMiddleware的请求——比如纯API服务若用Token认证、没启session，那这个中间件根本不起作用。

静态文件（/static/、/media/）走StaticFilesHandler或Nginx，绕过Django中间件链，完全不受CSRF限制
DRF项目若用TokenAuthentication且没启用session，CsrfViewMiddleware不会校验任何请求；要用SessionAuthentication才生效
如果视图加了@ensure_csrf_cookie，会强制写入csrftoken Cookie，哪怕当前请求是GET——适合前后端分离时提前“种”token

Django 3.1+默认设CSRF_COOKIE_SAMESITE = 'Lax'，这是安全的默认值。但如果你在本地用HTTP开发，又试图设'None'，浏览器会直接丢掉这个Cookie——因为SameSite=None必须搭配Secure=True（即HTTPS）。

开发时别强行改CSRF_COOKIE_SAMESITE = 'None'，保持默认'Lax'即可
上线前确保Nginx或负载均衡器终止HTTPS，并设置SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')，否则Django不知道该发Secure Cookie
检查响应头：Set-Cookie里是否含Secure; SameSite=Lax，没有就说明配置没生效

Django的CSRF防护本身很稳，真正出问题的地方永远在前后端协作的缝隙里：模板漏写{% csrf_token %}、AJAX没传头、本地HTTP硬配SameSite=None、或者误以为关掉中间件能“简化开发”。这些点不盯住，光看文档里的“已启用”三个字没用。