配置严格CORS的API是否仍需进行CSRF防护？

首先明确几个核心点，帮你理清风险：

1. CORS和CSRF是完全不同的防护机制 #

你说攻击者网站的脚本绕不过CORS，这点是对的，但CSRF攻击根本不需要绕过CORS——CSRF的核心是利用浏览器自动携带目标站点Cookie的特性发起请求，而它不需要读取请求的响应结果。不过你的情况特殊：认证token不通过Cookie传输，浏览器不会在跨域请求里自动带上你的Authorization头或存储在localStorage/内存里的token，所以常规的CSRF攻击（比如攻击者页面用表单提交、img标签触发GET请求）根本无法完成授权，这类攻击对你的系统无效。

2. 为什么仍建议保留CSRF防护？ #

虽然当前场景下CSRF风险极低，但它不是多余的：

• 未来兼容性：如果后续你的认证机制调整为Session Cookie（比如为了兼容某些场景），CSRF防护会立刻成为必要的安全屏障，提前配置好可以避免后续重构时遗漏。
• 兜底防御边缘场景：比如存在一些非AJAX的请求入口（哪怕现在用Angular很少见），或者某些极端情况下的浏览器同源策略漏洞，CSRF防护能提供额外一层保障。
• 框架默认规范：Angular本身就内置了CSRF防护的支持，Spring Boot也有成熟的配置方案，遵循框架的安全规范能减少人为失误。

3. XSS场景的补充 #

你提到XSS注入会自动发送CSRF token，这点没错——XSS脚本运行在你的域名下，完全可以获取到CSRF token、认证token等敏感信息，直接发起合法请求。这种情况下CSRF防护确实起不到作用，但XSS属于更严重的漏洞，需要通过内容安全策略（CSP）、严格的输入输出过滤等方式单独防御，和CSRF防护是互补关系，不能因为XSS的存在就否定CSRF的价值。

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