如果你做过前端开发，很可能见过这样的报错：「No 'Access-Control-Allow-Origin' header is present」。这个让无数人抓狂的错误，其实是一道安全防线。
CORS 是什么
浏览器的「同源策略」默认阻止网页向不同域名、端口或协议的服务器发起请求。CORS（跨域资源共享）是浏览器与服务器之间的「对话协议」：服务器在响应头里声明允许哪些来源访问，浏览器才会放行。打个比方：服务器在门口贴了张告示「仅限 zoom.us 入内」，浏览器才让来自 zoom.us 的请求进门；没这张告示，对不起，一律拦在门外。
一个常见的误解是「localhost 不受 CORS 约束」。实际上，浏览器对 localhost 和其他域名一视同仁，都会检查响应头中的 Access-Control-Allow-Origin。开发者之所以在本地开发时感觉 CORS 不起作用，往往是因为开发服务器配置了 Access-Control-Allow-Origin: *（允许任何来源），或者浏览器对 localhost 启用了调试模式。
Zoom 为什么用「图片尺寸」传递数据
2019 年，安全研究员 Jonathan Leitschuh 发现 Zoom 在用户电脑上运行了一个本地 Web 服务器（监听 localhost:19421），当用户访问 Zoom 链接时，网站会请求这个本地服务来启动桌面客户端。问题在于，如果用正常的 AJAX 请求，浏览器会检查 CORS 头，而这个本地服务器并没有返回正确的跨域授权。
Zoom 的解决方案是：请求一张「图片」，把数据编码在图片的宽高尺寸里。因为浏览器加载图片不受 CORS 限制，这个「图片请求」就能成功往返。但这个做法打开了另一个安全漏洞——不是只有 zoom.us 可以触发本地服务，任何网页都能向 localhost:19421 发起请求，进而操控Zoom客户端。
正确做法是什么
本地服务器只需在响应头中加入一行：
Access-Control-Allow-Origin: https://zoom.us
这相当于给大门换了把专用钥匙，只有来自 zoom.us 的页面才能进门，其他网站一律被浏览器拦截。同时，zoom.us 还应设置 Content Security Policy，禁止被嵌入 iframe，减少用户在不知情情况下被重定向打开会议的风险。
为什么这个问题值得重视
Zoom 的工程师或许只是想快速上线功能，但绕过 CORS 的代价是引入了一个影响所有用户的严重漏洞。Stack Overflow 上有大量「如何禁用 CORS」的提问，许多教程甚至直接建议把 Access-Control-Allow-Origin 设成 *。这些做法在测试环境能跑通，上了生产就可能成为攻击入口。
作者在文末抛出一个值得思考的问题：CORS 规范本身设计得是否过于复杂，还是开发者教育做得不够？无论如何，解决方案不是绕过安全机制，而是理解它、用对它。
编注：信源为技术博客（fosterelli.co），2019 年旧文重发以回应近期相关讨论；原文聚焦开发者对 CORS 的认知误区，材料以 Zoom 漏洞为唯一案例，未涉及其他安全议题。