Django为何用CORS框架优于手动校验request.headers['origin']

你自己在视图层手写origin校验的方案，本质是把CORS机制的复杂度想的太低了——CORS从来不是“判断origin等于允许值就完事”的简单逻辑，成熟的CORS框架比你手写的方案靠谱，核心原因有这几个：

• 你根本接不到CORS预检请求
  浏览器对跨域的非简单请求（比如带JSON请求体、带自定义头、用PUT/DELETE方法的请求），会先发一个OPTIONS方法的预检请求，确认服务端允许跨域之后才会发真正的业务请求。这类OPTIONS请求优先级很高，在Django的处理流程里，会被路由层、CSRF中间件、DRF的权限校验类提前拦截，根本不会走到你写的业务视图逻辑里。就算你想办法把OPTIONS请求放通到视图层，你还得自己手动拼接全套预检响应头：Access-Control-Allow-Methods、Access-Control-Allow-Headers、Access-Control-Max-Age，少一个头浏览器都会直接拦截响应，排查起来非常麻烦。

• 手写origin校验极易出bug和安全漏洞
  你写的request.headers['origin'] == 'example.com'本身就有问题：Origin头是带协议和端口的，正确值应该是https://example.com这种格式，漏了协议、端口的校验等于白写。如果要支持多源（开发环境的localhost、测试环境域名、带www/不带www的正式域名），自己写白名单匹配很容易出现绕过风险，比如写后缀匹配时被evilexample.com这种域名绕过。
  另外如果你的接口需要带凭证（Cookie、Authorization头），还得额外返回Access-Control-Allow-Credentials: true，这时候Access-Control-Allow-Origin不能用通配符*，必须返回精确匹配的源，这类规则细节非常多，自己写很容易要么功能不通，要么留下安全隐患。而且同源请求下浏览器根本不会带Origin头，你直接取request.headers['origin']还会触发KeyError，还得额外写异常兼容逻辑。

• 视图层校验覆盖不了所有请求路径
  你在单个业务视图里写的校验逻辑，只能覆盖对应接口的响应，项目里的其他路径：DRF自带的认证接口、第三方包的视图、Django Admin的接口、静态文件/Media文件响应、甚至400/403/500这类错误页的响应，根本不会走你写的业务视图，这些路径的跨域响应头自然也加不上，还是会报CORS错误。你总不能给所有第三方视图、全局错误处理逻辑都挨个加一遍校验，维护成本极高，后续加新接口漏加的概率非常大。

• 边缘场景的坑你踩不完
  CORS规范里还有大量细碎要求：比如前端要拿到自定义响应头（比如分页用的X-Total-Count），必须加Access-Control-Expose-Headers声明；不同浏览器（尤其是老版本Safari）对CORS的实现有特殊兼容逻辑；允许的头、方法的匹配规则细节等等。这些坑django-cors-headers这类成熟框架已经帮你踩完了，你自己从零写一套完全符合规范的逻辑，花的时间是装包配置的上百倍，最后写出来的东西还未必有框架稳定。

不是说你绝对不能自己实现CORS逻辑，只是完全没必要：CORS是浏览器强制执行的标准机制，没有什么定制化的特殊需求的话，用成熟中间件是性价比最高的选择——它会在Django请求流程的最早期介入，统一处理所有请求（包括预检OPTIONS），给所有匹配规则的响应加上正确的CORS头，你只需要改几行配置填好白名单就行，根本不用操心那些细碎的规则。

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