使用您网站的摘要'；s用于CSRF的身份验证cookie

您描述的方法在这里有详细说明：

跨站点请求伪造（XSRF）保护XSRF是一种由未经授权的网站可以获取您用户的私人数据。有棱角的提供了一种对抗XSRF的机制。当执行XHR请求时，$http服务从cookie中读取令牌（默认情况下，XSRF-token）并将其设置为HTTP报头（X-XSRF-TOKEN）。由于只有JavaScript在你的域上运行的可以读取cookie，你的服务器可以确保XHR来自您的域上运行的JavaScript。这个不会为跨域请求设置标头。

为了利用这一点，您的服务器需要在第一个HTTP上名为XSRF-TOKEN的JavaScript可读会话cookieGET请求。在随后的XHR请求中，服务器可以验证cookie与X-XSRF-TOKEN HTTP标头匹配，因此请确保只有在您的域上运行的JavaScript才能发送请求。令牌对于每个用户必须是唯一的，并且必须由服务器（以防止JavaScript制作自己的令牌）。我们建议该令牌是站点身份验证的摘要加盐饼干，增加安全性。

可以使用xsrfHeaderName和位于的$httpProvider.defaults的xsrfCookieName属性配置时间、运行时的$http.defaults或每个请求的配置对象

为了防止在多个角度应用程序共享相同的域或子域，我们建议每个应用程序使用唯一的cookie名称。

这似乎是加密令牌模式CSRF预防方法的变体，使用哈希而不是加密，并且salt的作用就像密钥。

它还依赖于一个HTTP功能，该功能可以防止自定义标头跨域发送，就像添加X-Requested-With一样。

声明"未经授权的网站可以获取用户的私人数据"的部分有点误导，因为CSRF不允许直接这样做——CSRF攻击允许未经授权网站在当前登录用户的情况下提交您的网站表格。

这种方法的一个优点是，您不需要在服务器端保存任何额外的东西。例如，如果您使用基于令牌的身份验证，则可以通过使用服务器端salt应用相同的哈希来轻松验证接收到的CSRF令牌是否与cookie匹配。即使您使用基于cookie的身份验证，也不需要根据服务器端存储的单独值来验证CSRF令牌——您只需对cookie值进行散列，即可验证它是否与传递的令牌匹配。

有关如何防止登录CSRF，请参阅此答案。