Django项目部署至AWS Elastic Beanstalk后登录触发CSRF验证403错误

• 本地运行时没有反向代理层，Django直接接收HTTP请求，默认信任本地域名（127.0.0.1、localhost），不需要额外配置即可通过CSRF校验。
• AWS Elastic Beanstalk 部署架构前端默认带有负载均衡（ALB）或Nginx反向代理，用户的HTTPS请求到达代理后，会以HTTP协议转发到后端Django实例：
  1. Django识别到请求为HTTP协议，不会设置带Secure属性的CSRF Cookie，而浏览器在HTTPS站点下会拒绝接收非Secure的Cookie，最终导致CSRF Cookie未设置的报错。
  2. Django 4.0及以上版本强制要求配置CSRF_TRUSTED_ORIGINS校验请求来源，生产部署的域名不在默认信任列表中，会触发校验失败。
  3. 若代理未正确传递原始请求的域名、协议信息，Django无法匹配CSRF Cookie的域名规则，也会导致校验失败。

注意：禁止注释django.middleware.csrf.CsrfViewMiddleware中间件，该配置是为了防范CSRF攻击，关闭后会产生严重的安全漏洞。

1. 配置Django识别代理转发的原始请求信息，在settings.py中添加以下配置：

# 信任负载均衡传递的X-Forwarded-Proto头，识别原始请求是否为HTTPS
SECURE_PROXY_SSL_HEADER = ('HTTP_X_FORWARDED_PROTO', 'https')
# 配置CSRF、会话Cookie仅通过HTTPS传输
CSRF_COOKIE_SECURE = True
SESSION_COOKIE_SECURE = True

2. 配置CSRF信任来源域名，同样在settings.py中添加，替换为你实际的部署域名：

CSRF_TRUSTED_ORIGINS = [
    # 替换为你的Elastic Beanstalk默认域名
    'https://xxx.xxx.elasticbeanstalk.com',
    # 若绑定了自定义域名，也需要添加
    'https://www.your-custom-domain.com'
]

3. （可选，仅当你手动修改过EB的反向代理配置时需要校验）确认反向代理（Nginx/ALB）已正确传递以下请求头：
   • X-Forwarded-Proto：原始请求的协议（http/https）
   • X-Forwarded-Host：原始请求的域名

配置完成后重新部署即可恢复正常登录。

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