并非所有浏览器都使用HTTP_ORIGIN。HTTP_ORIGIN有多安全?对我来说，它在FF中是空的。 我有网站，我允许访问我的网站发送一个网站ID，然后我检查我的数据库记录与ID，并获得SITE_URL列值(www.yoursite.com)。

header('Access-Control-Allow-Origin: http://'.$row['SITE_URL']);

即使发送了一个有效的站点ID，请求也需要来自我的数据库中列出的与该站点ID相关的域。

对于ExpressJS应用程序，您可以使用:

app.use((req, res, next) => {
    const corsWhitelist = [
        'https://domain1.example',
        'https://domain2.example',
        'https://domain3.example'
    ];
    if (corsWhitelist.indexOf(req.headers.origin) !== -1) {
        res.header('Access-Control-Allow-Origin', req.headers.origin);
        res.header('Access-Control-Allow-Headers', 'Origin, X-Requested-With, Content-Type, Accept');
    }

    next();
});

我们也可以在全局中设置这个。asax文件用于Asp.net应用程序。

protected void Application_BeginRequest(object sender, EventArgs e)
    {

    // enable CORS
    HttpContext.Current.Response.AddHeader("Access-Control-Allow-Origin", "https://www.youtube.com");

    }

也许我错了，但据我所知，Access-Control-Allow-Origin有一个“origin-list”作为参数。

根据定义，origin-list为:

origin            = "origin" ":" 1*WSP [ "null" / origin-list ]
origin-list       = serialized-origin *( 1*WSP serialized-origin )
serialized-origin = scheme "://" host [ ":" port ]
                  ; <scheme>, <host>, <port> productions from RFC3986

由此，我认为不同的起源是被承认的，并且应该被空间分隔开。

有一个缺点你应该知道:一旦你将文件外包到CDN(或任何其他不允许脚本的服务器)，或者如果你的文件缓存在代理上，根据“Origin”请求头更改响应将不起作用。

匹配子域的PHP代码示例。

if( preg_match("/http:\/\/(.*?)\.yourdomain.example/", $_SERVER['HTTP_ORIGIN'], $matches )) {
        $theMatch = $matches[0];
        header('Access-Control-Allow-Origin: ' . $theMatch);
}