Access-Control-Allow-Origin是否足以防止XSRF攻击？
我们正在构建一个带有在JBoss中运行的Java Spring / Hibernate后端的应用程序。 前端是AngularJS。
我们还没有做任何事情来在服务器端设置XSRF令牌。 我们也不（无论如何）要求允许其他域访问我们的Web资源。
我想我会试着看看我们的网站是否容易受到XSRF攻击，所以我建立了一个恶意网络应用程序，使用Angular的$ http.post（）发布到我们真正的应用程序url之一。 我登录到真正的应用程序，然后我尝试从恶意应用程序发布。
在浏览器中，我收到了401响应并看到了错误：
XMLHttpRequest cannot load http://localhost:8080/user/delete. No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:6543' is therefore not allowed access. The response had HTTP status code 401. 服务器端未设置为在响应上设置Access-Control-Allow-Origin，因此出现上述错误。
所以我的问题是，只是从响应头中省略了Access-Control-Allow-Origin，足以防止XSRF攻击？
有没有办法我仍然可以在我的网站上进行XSRF攻击，即使没有设置Access-Control-Allow-Origin？ 如果是这样的话？ 我想演示这次攻击。
谢谢。
不，这还不够。 即使浏览器提供'Access-Control-Allow-Origin'错误，该请求仍由浏览器发出。 如果攻击页面指定了withCredentials ：
$http.post(url, {withCredentials: true, ...})
然后，此请求将使用受害者的身份validationcookie发送到您的域，这意味着对http://www.example.com:8080/user/delete的请求将成功。
此外，也可以使用标准HTML表单在没有XHR的情况下进行此请求：
和JavaScript只会用于提交表单而不是自己提出请求。
保护系统免受CSRF影响的一种简单方法是检查自定义标头，例如X-Requested-With或Origin标头。 如果不启用CORS服务器端，则无法跨域发送X-Requested-With 。 但是， 同步器令牌模式仍然是CSRF预防的最强方法，因为它不受浏览器插件中的缺陷的影响，例如Flash中的先前缺陷允许发送通常不可能从浏览器发送的标头。