关于 CORS 的一个问题，大家怎么看

昨天先去了解了下同源策略，然后又去看了一些和 CORS 相关的文章，几乎所有的文章都告诉我只要在响应头中加入几个 Access-Control-* 头部就可以了。比如像这样：

header('Access-Control-Allow-Origin:http://www.startphp.cn');
header('Access-Control-Allow-Methods:POST');
header('Access-Control-Allow-Headers:x-requested-with, content-type');

这段代码是我从别的地方复制过来的，不同文章的具体代码不一样，但都是差不多的，只不过多几个头部或者某个头部的值不一样罢了，没什么本质区别。

服务端这样做确实可以通知客户端，让其拒绝服务端返回的响应，但是服务端关于 CORS 的全部工作就这些么？我觉得不是！至少还应该加一些处理，起码应该在适当的时候结束程序的执行，如果服务端都准备告诉客户端拒绝自己的响应了，那发完响应头部，就没必要再执行后续的业务逻辑了，不是么？反过来说，所有的逻辑都执行完了，然后你再加几个头部去告诉客户端把自己拒绝掉，这不是多此一举么？

我知道客户端只要不发送 Origin 头部，就可以绕过服务端的 CORS 处理；我也知道要想提升安全性，必须得做鉴权才行，但就是觉得服务端的 CORS 处理这块还是应该稍微完善一点，不应该只是加几个头部就草草的结束了才对。如果你觉得我的这种想法是有问题且多余的，欢迎留言指正！

最后我列出我的一点代码，代码并没有做过测试，也更没在开发环境和生产环境中使用过，只是想说明一下我觉得完善的 CORS 处理大概应该是什么样子。具体的逻辑主要参考的是阮一峰的这篇文章：《跨域资源共享 CORS 详解》。有兴趣的伙伴可以去看看。

<?php

// CORS 配置
$config = [
    'allow_origin' => ["http://b.example.com", "http://c.example.com"],
    'allow_method' => ['GET', 'POST', 'PUT', 'DELETE', 'OPTIONS'],
    'allow_headers' => ['X-Custom-Header', 'Accept'],
    'expose_headers' => ['Content-Range'],
    'allow_credentials' => true,
    'max_age' => 86400,
];

// CORS 预检请求
if (isCorsPreflightRequest()) {
    // 检查预检请求
    if (checkCorsPreflightRequest($config)) {
        // 通过
        addCorsPreflightRequestHeaders($config);
    } else {
        // 未通过，什么也不做
    }
    // 退出，不进入业务逻辑部分
    exit;
}

// CORS 简单请求
if (isCorsSimpleRequest()) {
    // 检查简单请求
    if (checkCorsSimpleRequest($config)) {
        // 通过
        addCorsSimpleRequestHeaders($config);
    } else {
        // 没通过，退出，不进入业务逻辑部分
        exit;
    }
}

function isCorsPreflightRequest(): bool
{
    return isset($_SERVER['HTTP_ORIGIN'], $_SERVER['REQUEST_METHOD']) &&
        'OPTIONS' === strtoupper($_SERVER['REQUEST_METHOD']);
}

function checkCorsPreflightRequest(array $config): bool
{
    return checkCorsOrigin($config) && checkCorsRequestMethod($config) && checkCorsRequestHeaders($config);
}

function checkCorsOrigin(array $config): bool
{
    return '*' === $config['allow_origin'] || in_array($_SERVER['HTTP_ORIGIN'], $config['allow_origin'], true);
}

function checkCorsRequestMethod(array $config): bool
{
    if (
        isset($_SERVER['HTTP_ACCESS_CONTROL_REQUEST_METHOD']) &&
        !in_array(strtoupper($_SERVER['HTTP_ACCESS_CONTROL_REQUEST_METHOD']), $config['allow_method'], true)
    ) {
        return false;
    }
    return true;
}

function checkCorsRequestHeaders(array $config): bool
{
    if (isset($_SERVER['HTTP_ACCESS_CONTROL_REQUEST_HEADERS'])) {
        $requestHeaders = explode(',', $_SERVER['HTTP_ACCESS_CONTROL_REQUEST_HEADERS']);
        $allowHeaders = array_map(fn($header) => strtoupper($header), $config['allow_headers']);
        foreach ($requestHeaders as $requestHeader) {
            $requestHeader = strtoupper(trim($requestHeader));
            if (!in_array($requestHeader, $allowHeaders, true)) {
                return false;
            }
        }
    }
    return true;
}

function addCorsPreflightRequestHeaders(array $config): void
{
    if ('*' === $config['allow_origin']) {
        header('Access-Control-Allow-Origin: *');
    } else {
        header('Access-Control-Allow-Origin: ' . $_SERVER['HTTP_ORIGIN']);
    }
    header('Access-Control-Allow-Methods: ' . implode(',', $config['allow_method']));
    header('Access-Control-Allow-Headers: ' . implode(',', $config['allow_headers']));
    header('Access-Control-Allow-Credentials: ' . ($config['allow_credentials'] ? 'true' : 'false'));
    header('Access-Control-Max-Age: ' . $config['max_age']);
}

function isCorsSimpleRequest(): bool
{
    return isset($_SERVER['HTTP_ORIGIN']);
}

function checkCorsSimpleRequest(array $config): bool
{
    return checkCorsOrigin($config);
}

function addCorsSimpleRequestHeaders(array $config, array $exposeHeaders = []): void
{
    if ('*' === $config['allow_origin']) {
        header('Access-Control-Allow-Origin: *');
    } else {
        header('Access-Control-Allow-Origin: ' . $_SERVER['HTTP_ORIGIN']);
    }
    if (empty($exposeHeaders)) {
        header('Access-Control-Allow-Headers: ' . implode(',', $config['expose_headers']));
    } else {
        header('Access-Control-Allow-Headers: ' . implode(',', $exposeHeaders));
    }
    header('Access-Control-Allow-Credentials: ' . ($config['allow_credentials'] ? 'true' : 'false'));
}

// 假设下方是业务逻辑部分的代码
// 省略...

asiufasd

2020-09-02 18:48:35 +08:00

@mitu9527 本意是想让您自己再看一遍的，回答了那些问题我觉得就可以回答您的问题了。
我帮您整理好您看一下。
以下引用自您发出来的文章，
1. “如果 Origin 指定的源，不在许可范围内，服务器会返回一个正常的 HTTP 回应。浏览器发现，这个回应的头信息没有包含 Access-Control-Allow-Origin 字段（详见下文），就知道出错了，从而抛出一个错误”，“如果服务器否定了"预检"请求，会返回一个正常的 HTTP 回应，但是没有任何 CORS 相关的头信息字段。这时，浏览器就会认定，服务器不同意预检请求，因此触发一个错误”；
所以无论是简单请求还是非简单请求，跨域检测失败的响应头里都不会包含 CORS 相关的头信息字段，所以让客户端拒绝服务端，不需要特别返回响应头。
2. “非简单请求的 CORS 请求，会在正式通信之前，增加一次 HTTP 查询请求，称为"预检"请求（ preflight ）。
浏览器先询问服务器，当前网页所在的域名是否在服务器的许可名单之中，以及可以使用哪些 HTTP 动词和头信息字段。只有得到肯定答复，浏览器才会发出正式的 XMLHttpRequest 请求，否则就报错。”，预检的响应头会包含你最开始列出的一些 Access-Control-*头（如果后端允许请求的话）；
这个请求是 options 请求，预检请求，并不会执行具体的逻辑，只有后端预检通过后，客户端才会发出正式的 XMLHttpRequest 请求。不存在"所有的逻辑都执行完了，然后你再加几个头部去告诉客户端把自己拒绝掉 "的问题、

also24

2020-09-02 19:03:57 +08:00

尝试着帮楼主解释一下。

首先是大前提，楼主的思考方向，是在『无框架协助』情况下，处理后端请求。
划重点：无框架

第 1 条，关于 OPTIONS 请求的处理：
由于无框架，所以不管你的请求 method 是 GET POST 还是 OPTIONS，都会进入整个请求处理逻辑。
自然的，OPTIONS 请求也直接进来了，如果你不将它单独处理，那确实可能造成问题。

第 2 条，关于浏览器对跨域请求的拦截：
@lalalaqwer #7 你的理解是有一定问题的，浏览器对于跨域请求，未必是在『发送请求』阶段拦截。
你可以找个 Chrome 浏览器测试一下，Chrome 只是拦截了返回内容，服务器上你是可以收到这条请求的。

由于以上两条，在『无框架』的场景下，确实有可能出现后端对跨域请求处理不合理，导致浏览器的 CORS 机制没有正确生效的情况。

但是为什么很多人都不认可楼主的结论呢？
第 1 条是因为『无框架』的场景实在是太少啦，现在基本上大事小事都会起框架，而框架往往都会对 OPTIONS 请求做自动处理。
第 2 条，则真的是很多人没有注意过，因为各类文档上往往只会提到『浏览器拦截跨域请求』，却没有详细的说明是在哪一个阶段拦截的。