如果我有：
- 一个域上的web前端
- 另一个域上的REST API
- REST API服务器配置为仅允许来自web前端域的交叉源请求，方法是将头
Access-Control-Allow-Origin设置为web前端域
除了更多的障碍，CSRF还提供了哪些额外的安全保障？攻击者不能在不首先将代码注入web前端的情况下将D_2 POST发送到我的后端，对吧？
关于这个问题，Chris Pratt说，"[...]So, yes, I think as a rule any API view should be CSRF exempt.[...]"。这个概念有效吗？它包括我的拓扑结构吗？
在我的配置中，在正确配置CORS的情况下，我是否需要用Cookie和数据元素CSRF令牌装饰来自web前端的GET、POST、PUT和DELETE请求？
元：
开明的人可能认为这个问题是重复的，但我读过这个，这这这这这并且，我仍然需要一些帮助。请帮我进一步充实这个想法。
在从域加载页面的上下文中，CORS仅控制浏览器是否可以从另一个域读取XHR响应。它不控制浏览器可以向发出请求的域。也就是说，CORS将放宽由您的头设置的任何来源的同源政策，但同源政策中没有任何内容表明不能首先提出请求。
其他域仍然可以GET和POST到您的域，只是除非CORS允许，否则您的站点生成的任何响应都不能在客户端脚本中读取。实际的GET和POST仍然由服务器接收并处理。
因此，您仍然需要防止CSRF，即使对于具有符合CORS的浏览器的用户也是如此。
在CSRF攻击中，攻击者的网站使用浏览器中仍然有效的身份验证cookie发布到网站或API。
如果您将CORS设置为只允许来自您的站点的请求，则请求将失败，因为任何现代浏览器都会添加一个指示攻击者站点的原始标头。
但这取决于这样一个事实，即所有用户都使用符合CORS的浏览器。由于CORS仍然很新，所以我不认为这是什么。如果使用cookie进行身份验证，我建议将CSRF保护添加到您的API。
但更好的解决方案是不要将API建立在cookie身份验证的基础上，而是使用基于令牌的安全性，这不易受到CSRF攻击。