有时，在对生产中的错误进行故障排除时，能够从我的本地开发环境中访问我们的生产REST服务器会很方便。但我担心将localhost添加到允许的来源将是一个安全风险。搜索产生了相互矛盾的信息。我的担忧有效吗？为什么或为什么不呢？
答案 0 :(得分：14)
我假设你有
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: https://localhost
风险是用户计算机上运行的任何服务都可以有效绕过您网站的Same Origin Policy。
因此，如果您有一个REST URL，例如
https://example.com/User/GetUserDetails
在用户计算机上运行的恶意或受损服务可以通过用户的浏览器发出该请求，然后获取有关该用户的详细信息，因为他们的身份验证cookie将随请求一起传递。
现在，您可以争辩说，在用户计算机上运行的恶意服务可以直接从浏览器中获取身份验证cookie，然后自行发出请求。但是，如果该服务有自己的一些缺陷（比如XSS），这可能会允许其他站点通过您的REST服务（evil.example.org --XSS-> localhost -CORS-> example.com/User/GetUserDetails）来破坏用户。
如果用户正在运行本地反向代理来访问某些内容，则可能会使您面临风险。如果目标站点是恶意的或受到攻击，这将使目标站点能够通过您的站点危害用户。这是因为用户将使用域localhost访问目标站点。
如果您确实需要这样做，我建议您为REST服务设置一个特殊的开发人员帐户，访问时只会在您的请求中添加Access-Control-Allow-Origin: https://localhost标头。这样，您就不会让其他用户面临风险，因为您知道您只在https://localhost运行前端服务器，因此您不会受到开放式CORS设置的影响。
另一种方法可能是使用noonewouldusethis2859282.localhost之类的东西作为前端的本地副本。然后你可以安全地添加Access-Control-Allow-Origin: https://noonewouldusethis2859282.localhost标题，因为没有其他人会使用它，并且可以安全地免受CORS攻击。
答案 1 :(得分：2)
将localhost添加到生产中的CORS设置中没有安全问题。
添加以下内容：
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: http://localhost:3000
现在允许浏览器绕过Same Origin Policy从localhost：3000拨打您的服务。现在，任何Web开发人员都可以创建一个从本地计算机运行的网页来调用您的API，这对您的团队非常有用。但是，localhost不是publicly routable address - 您无法共享指向http://localhost:3000的链接。请记住，CORS只是用于调用您网站的Web浏览器的安全措施。任何人仍然可以通过服务器到服务器调用（或脚本）调用您的端点。但是，您应避免：
Access-Control-Allow-Credentials: true
Access-Control-Allow-Origin: *
这将使您的网站可用于每个网站。相反，请将Access-Control-Allow-Origin锁定到需要它的网站。不幸的是，Access-Control-Allow-Origin只接受一个值，因此您必须处理HOST请求服务器端并返回有效值（more info）。
当您发出需要身份验证的CORS请求时，您应该在呼叫中添加Authorization标头，而不是传递Cookie -
fetch does this by default。因此，对CORs端点的任何调用都将通过javascript将标记添加到它仅对该会话具有的标头中进行。如果您通过cookie或localstorage存储令牌，请注意它只能从该域（more info）访问。您的生产端点和localhost将不具有相同的cookie和共享本地存储。
最后，您可以通过--disable-web-security（more info）启动Chrome，从Chrome向任意网站发出CORS请求。
最后，Google Chrome只允许服务工作者在安全网站和http://localhost上运行。如果您选择创建local.example.com进行开发，则需要创建SSL证书并在本地计算机上执行所有配置以使其运行。我建议只使用http://localhost:XXXX。