Spring Security已实现服务器端SOP，为何WebSocket连接仍需CSRF防护？

核心问题拆解 #

• 已实现服务器端同源策略（SOP），还会发生CSRF攻击吗？
• WebSocket连接请求属于简单请求吗？
• 仅靠服务器端Origin校验是否足够？

逐一解答 #

1. 服务器端SOP+Origin校验仍可能存在CSRF风险？ #

虽然浏览器无法篡改Origin请求头，但存在Origin伪造的边缘场景：比如早期浏览器的漏洞、非浏览器客户端发起的请求等。不过标准浏览器环境下的常规请求，Origin校验确实能拦截大部分跨源请求。Spring Security要求CSRF令牌，是遵循“深度防御”的安全原则——即使Origin校验出现疏漏，CSRF令牌能作为第二道防线。

2. WebSocket连接请求是否属于简单请求？ #

WebSocket的握手请求（即GET请求升级为WebSocket）不属于CORS定义的简单请求。简单请求限定特定方法（GET/POST/HEAD）+特定请求头，而WebSocket握手会携带Upgrade、Connection等特殊头，它有自己的跨源处理逻辑：浏览器会在握手时自动携带Origin头，服务器需自行校验这个头来实现SOP。

3. 仅靠Origin校验是否足够？ #

从标准浏览器环境的常规攻击场景来看，严格的Origin校验（精确匹配允许的域名，不使用通配符）已经能有效防范CSRF。但Spring Security强制要求CSRF令牌，是出于以下考虑：

• 深度防御：多一层防护，避免因Origin校验逻辑漏洞（比如误判通配符、正则匹配错误）导致的风险；
• 非浏览器客户端：攻击者使用非浏览器工具发起WebSocket连接时，可能绕过浏览器的Origin自动携带机制，此时CSRF令牌能验证请求合法性；
• 规范统一：Spring Security的设计倾向于对齐WebSocket和常规HTTP请求的安全防护模型，减少配置疏漏。

补充：Spring Security官方明确要求：所有入站CONNECT消息都需要有效的CSRF令牌以强制执行同源策略。

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