升级Django到4.1：如何决定是否启用CSRF_COOKIE_MASKED及测试方法

一、要不要开 CSRF_COOKIE_MASKED？ #

首先明确：Django 4.1 默认是关闭这个设置的（CSRF_COOKIE_MASKED = False），这是官方推的新做法——以前给CSRF Cookie加掩码是为了对付老浏览器的漏洞，现在这些漏洞早就没威胁了，关了还能少点性能损耗。

只有两种情况需要临时开：

• 你的App还在支持IE 10及更早的古董浏览器，这类浏览器有泄露CSRF Cookie的风险，开掩码能降低隐患；
• 你有自定义的CSRF处理逻辑（比如前端自己读Cookie塞请求头，不用Django的{% csrf_token %}标签），而且旧代码依赖掩码后的Cookie值，暂时改不了前端，那就先开着过渡，之后再重构代码。

没上述情况的话，直接用默认的关闭状态就行，跟着官方优化走准没错。

二、怎么验证这个变更没问题？ #

1. 核心功能测试 #

• 把App里所有带CSRF保护的表单、AJAX请求都提交一遍，确保不会弹出403 Forbidden (CSRF验证失败)的错误；
• 用浏览器F12看Cookie：找到CSRF Cookie的值，再对比页面里{% csrf_token %}生成的隐藏输入框值——关掩码的话两者完全一样，开掩码的话Cookie值会带前缀，输入框里是原始令牌。

2. 兼容性测试 #

• 如果开了掩码，就在你要支持的老旧浏览器里再测一遍表单提交，确保功能正常；
• 如果关了掩码，确认新浏览器（Chrome、Firefox、Edge这些）里所有请求都没问题就行。

3. 自定义逻辑验证 #

• 要是你有前端自己读CSRF Cookie的代码（比如AJAX手动设X-CSRFToken头），得专门测这些请求：
  • 关掩码时，直接读Cookie值塞请求头就正常；
  • 开掩码时，得确保代码能正确解析掩码后的Cookie（Django自带的get_token()方法会自动处理，但自己写的代码可能要适配）。

4. 自动化测试补全 #

• 在你的自动化测试用例里加个CSRF专项测试：模拟表单提交、AJAX请求，断言返回的是200状态码（不是403）；
• 用Django测试客户端的client.cookies属性，检查CSRF Cookie的格式，看是不是符合你设置的掩码状态。

内容的提问来源于stack exchange，提问作者Gagan