在我的应用程序中，我包含了来自不同服务器/域的页面。为简单起见，我将参考我的主要应用程序 Web A ，以及其他 Web B 。
某处我 A ，在用户登录后，我将使用CORS和jwt从 B 加载页面。 在 A 中，我创建了一个传递给Ajax的编码令牌。 Ajax在标题内添加了此标记（＆＃34;授权＆＃34; = 承载+编码标记）。
B 然后使用此令牌解码并获取它所属的usersId和组，并确定用户是否有权访问该资源。 此外，Web B中还有一个 Access-Control-Allow-Origin = Web A 设置，仅接受来自A的请求。
我的问题是关于CORS的安全部分和jwt的用法。 在开发过程中，当使用Postman直接访问 B 中的资源时，我可以轻松绕过＆＃34; Access-control-allow-origin ＆＃34; 。 只要我有正确的令牌，资源就会被送回来没有问题！我的意思是只需要一些潜在的黑客获取该编码的字符串，他们就可以轻松地使用Postman查看资源。
安全部分的下一步是什么，因为我完全迷失了！
希望我能清楚地解释这个问题。非常感谢所有帮助
答案 0 :(得分：5)
如果攻击者获取用户的JWT访问令牌并直接从Web B请求资源，则CORS并不意味着保护您。
实际上，CORS根本不是安全功能，而是一种安全地绕过浏览器的同源策略（安全功能）的方法。同源策略（基本上每个浏览器都实现）限制网页访问来自不同来源的网页上的数据。
想象一下浏览器没有实现同源策略的情况。任何网页都可以从任何来源请求数据，这意味着任何恶意网站都可以从银行，电子邮件帐户或其他任何地方请求数据。这个浏览器很乐意发送与这些来源相关的任何HTTP cookie，并且所有这些请求都将被授权。对这个浏览器的攻击是微不足道的。
因此，显然任何浏览器都需要同源策略。但是，正如您所知，网站在原始数据库之间共享数据通常很有用。这就是CORS规范创建的原因。只要双方同意共享数据来源，浏览器就会允许发送请求。
要回答您的真实问题，阻止攻击者直接使用JWT的方法是首先不允许他们访问JWT。您应该像保存HTTP会话cookie或密码一样保护JWT，因为它就是这样。
答案 1 :(得分：1)
这是完全正确的。 CORS的存在是为了保护用户的Web浏览器。直接浏览或卷曲到站点B不受CORS保护。服务器可以从各种客户端获得任何类型的请求，并且必须自行保护。
站点B的安全性来自正确使用JWT（最好是通过HTTPS）。首先，令牌用秘密签名。这让你知道别人没有改变它或自己创造一个。其次，有效载荷应包括相对较短的到期时间。在这段时间之后，令牌的接收者应该忽略它，因此掌握令牌的中间人很少有时间使用它。第三，如果你只通过HTTPS传递令牌，那么你很少有人能够获得它。