前端报cross-origin-request-blocked错误时为何后端仍会处理请求

CORS拦截的本质 #

你首先要明确一个核心认知：CORS是浏览器端的安全限制，而非服务端的安全机制。
浏览器的跨域拦截逻辑发生在请求已经完整发送到服务端、且服务端已经处理完请求返回响应之后，浏览器检查响应头里的Access-Control-Allow-Origin等CORS相关字段不符合要求，才会把响应内容吞掉，给前端抛出跨域错误，整个过程服务端是感知不到的，也不会主动中断业务代码的执行。

问题1：Express是否应当在Origin不被允许的情况下阻止后续代码运行？ #

默认情况下Express本身没有内置的Origin校验逻辑，你贴的代码里的CORS中间件只是注释了响应头的设置，没有做任何Origin合法性判断和拦截逻辑，所以请求会正常进入路由执行业务代码，这是符合预期的。

如果你需要让不合法Origin的请求不执行业务逻辑，可以自行在中间件中增加校验逻辑，示例如下：

const ALLOWED_ORIGINS = ['https://your-frontend-domain.com', 'http://localhost:3000']
app.use(function (req, res, next) {
    const origin = req.headers.origin
    // 校验origin是否在允许的白名单中
    if (origin && !ALLOWED_ORIGINS.includes(origin)) {
        // 不合法直接返回403，不调用next()，后续路由逻辑不会执行
        return res.sendStatus(403)
    }
    res.header("Access-Control-Allow-Origin", origin || "*")
    res.header("Access-Control-Allow-Headers", "Origin, X-Requested-With, Content-Type, Accept")
    // 预检请求直接返回200
    if (req.method === 'OPTIONS') {
        return res.sendStatus(200)
    }
    next()
});

问题2：前端收到跨域报错但后端代码仍执行的情况是否存在安全威胁？ #

这个情况存在明确的安全风险，尤其是针对会修改服务端数据的非幂等接口：

• 对于纯查询类的GET接口，风险相对较低，因为恶意网站的前端拿不到接口返回的敏感数据
• 对于POST/PUT/DELETE等会新增、修改、删除数据的接口，风险极高：就算恶意网站的前端拿不到响应结果，请求已经发送到服务端执行业务逻辑，完全可以实现CSRF攻击，比如调用转账、修改密码、删除数据的接口，直接造成实际损失。

对应的防范建议： #

• 所有修改数据的接口禁止使用GET方法，强制使用POST/PUT等方法
• 接口增加CSRF Token校验，或者校验请求的Referer头
• Cookie设置SameSite属性，避免第三方网站携带用户Cookie发起请求
• 服务端主动做Origin白名单校验，不合法的请求直接拦截，不执行业务逻辑

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