websocket握手不校验cors，防御cswsh必须服务端显式验证origin头，禁用通配符，配合wss、token认证等措施。
WebSocket 在握手阶段不走 CORS 策略校验，CORS 对 WebSocket 完全无效。真正起作用的是服务端对 Origin 请求头 的显式校验——这是防御跨站 WebSocket 劫持（CSWSH）的核心手段。
WebSocket 握手不依赖 CORS
浏览器发起 WebSocket 连接时，会自动在 HTTP 升级请求中带上 Origin 头（如 Origin: https://attacker.com），但它不会检查服务端响应中的 Access-Control-Allow-Origin 等 CORS 头。即使你设置了这些响应头，浏览器也完全忽略——因为握手成功后协议已切换为 WebSocket，不再适用 HTTP 跨域机制。
所以，把 CORS 配置套用到 WebSocket 服务上，属于典型误解。无效配置包括：
- 在 ws 服务响应中写
Access-Control-Allow-Origin: * - 用 Express 的
cors()中间件包裹 WebSocket 路由 - 期望浏览器像处理 fetch/XHR 那样执行预检（OPTIONS）
必须由服务端校验 Origin 头
防御 CSWSH 的唯一有效方式，是在握手阶段（即收到 Upgrade 请求时）读取并验证 Origin 请求头的值，只放行可信来源。
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
以 Node.js + ws 库为例，通过 verifyClient 钩子实现：
- 提取
req.headers.origin（注意大小写，实际可能是origin或Origin） - 比对白名单（如
['https://myapp.com', 'http://localhost:3000']） - 不匹配则返回
false，连接被拒绝（HTTP 403） - 禁止使用通配符
*，避免开放全部来源
配套安全措施不能少
仅校验 Origin 不足以覆盖全部风险，还需结合其他实践：
- 始终使用
wss://（而非ws://），防止中间人窃听或篡改握手 - 确保反向代理（如 Nginx）透传关键头：
Upgrade和Connection，否则握手无法抵达后端 - 身份认证不依赖 Cookie 单一机制；建议在握手 URL 中携带短期有效 token（如
wss://api.example.com?token=xxx），服务端验证后再建立连接 - 避免在 WebSocket 消息中回传敏感数据，除非已确认连接来源合法且会话可信
前端无法单靠 JS 规避该漏洞
JavaScript 侧无法阻止恶意页面发起 WebSocket 连接——浏览器允许任意源调用 new WebSocket()。也就是说：
- 你不能靠
document.domain或postMessage拦截跨源连接 - 前端无权读取或修改握手请求的
Origin头 - 所谓“前端 CORS 设置”对 WebSocket 无意义
所有防护逻辑必须落在服务端握手环节。前端能做的，只是确保自身页面不被 XSS 注入后用于发起恶意连接。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
