看官方指南 http 服务页面的一点点笔记。（一个多月之前学习时留下的笔记，现在也没时间继续学习了，就把笔记贴着吧）
安全考虑
当设计一个网络应用时，需要考虑两种安全威胁：
为了消除这种安全性威胁，客户端和服务器端需要相互协作。Angular 自带有安全策略配置来解决这些问题，但是需要后端服务器的支持。
JSON Vulnerability(脆弱性，弱点) Protection
一个 JSON vulnerability 允许第三方网站在某些条件下将你的 JSON 格式的资源 URL 转换为 JSONP请求。为了解决这个问题，你的服务器可以在响应 JSON 请求时在响应体上加入前缀字符串 ")]}',\n"。Angular 在处理 JSON 响应前会自动除去这个前缀。
例如，如果你的服务器需要返回如下内容：
这是脆弱的，且容易被攻击，你的服务器可以返回如下内容：
Angular 在处理 JSON 响应数据之前将会自动除去前缀。
Cross Site Request Forgery(XSRF) Protection
XSRF 是一种攻击者伪装成已认证用户在你的网站上执行一些授权操作的攻击技术。Angular 提供了一种机制来阻止 XSRF。当发起 XHR 请求时，$http 会从 cookie 中读取一个 token（默认是 XSRF-TOKEN）并把它设置为一个 HTTP 请求头部字段（X-XSRF-TOKEN）。因为只有运行在你域名下的 JavaScript 脚本才可以读取你域名下的 cookie，
因此你的服务器端可以通过这个字段来确保请求来自你域名下的 JavaScript 脚本。跨域名的请求将无法设置这个请求头。
利用这一点，你的服务器端需要在接收到客户端第一次发送的 HTTP GET 请求后设置一个只有 JavaScript 脚本可读的 XSRF-TOKEN cookie。在接下来的 XHR 请求中，服务器可以验证 cookie 中的 XSRF-TOKEN 字段的值是否匹配 HTTP 头部字段 X-XSRF-TOKEN 的值，并依次确保只有运行在你域名下的 JavaScript 脚本可以发送请求。这个 token 的值必须针对每一个用户拥有唯一性，并且服务器端可以校验这个值（为了防止攻击者自行伪造自己的 token）。我们推荐做法是将你站点的认证 cookie 加盐) 后取摘要来增加安全性。
这个头部字段名可以在配置阶段或者运行阶段使用 $httpProvider.defaults 的 xsrfHeaderName 和 xsrfCookieName 属性自行指定，也可以在请求的 config 对象中指定。
为了防止共享域名或子域名的多个 Angular 应用产生冲突，我们建议每个应用使用单独的 cookie 名。
单词
Forgery，伪造