anchor.diff:    `Content-Security-Policy` HTTP header. Learn more at
     [OWASP](https://www.owasp.org/index.php/Content_Security_Policy).
   
  +  [内容安全策略(CSP)](https://developer.mozilla.org/en-
  +  US/docs/Web/Security/CSP/Introducing_Content_Security_Policy)是用来防止XSS的深度防御技术。
  +  为了打开CSP，配置你的Web服务器，让它返回合适的`Content_Security_Policy` HTTP头字段。参见[OWASP](https://www.owasp.org/index.php/Content_Security_Policy)。
  +
     <a id="offline-template-compiler"></a>
     ### Use the Offline Template Compiler
  +
  +  ### 使用离线模版编译器
   
     The offline template compiler prevents a whole class of vulnerabilities called template injection,
     and also greatly improves application performance. Use the offline template compiler in production
  
positive.code:   generate Angular templates on the server side using a templating language, this carries a high
    risk of introducing template injection vulnerabilities.
  
  .l-main-section
  h2#bypass-security-apis Trusting Safe Values
  :marked
    Sometimes applications genuinely need to include executable code, display an `<iframe>` from some
    URL, or construct potentially dangerous URLs. To prevent automatic sanitization in this situation,
  
negative.code:   each API request, the server then validates the client by checking that the token is sent back,
    usually in an HTTP header called `X-XSRF-TOKEN`.
  
    为了防止这种情况，你的应用程序必须确保每个用户的请求都是从你自己的应用程序发出的，而不是从一个不同的站发出的。
    一个常见的技术是服务器随机生成一个用户认证令牌到cookie中，通常它的名字是`XSRF-TOKEN`。
    Cookie只能被创建它的网站访问，所以你自己的应用程序能读取这个令牌。每收到一个API请求，服务器都会验证客户端，
    检查这个发回来的令牌，它通常在HTTP头字段里，叫做`X-XSRF-TOKEN`。
  
    The Angular `http` client has built-in support for this technique. The default
    `CookieXSRFStrategy` looks for a cookie called `XSRF-TOKEN` and sets an HTTP request header named
    `X-XSRF-TOKEN` with the value of that cookie on every request. The server must set the
    `XSRF-TOKEN` cookie, and validate the response header for each state modifying request.
  
    Angular的`http`客户端对这个技术有内建支持。默认的`CookieXSRFStrategy`寻找一个名叫`XSFR-TOKEN`的cookie。
    在每个请求中，设置一个名为`X-XSRF-TOKEN`的HTTP请求头字段，并把cookie的值赋给它。服务器必须设置`XSRF-TOKEN`cookie，
    并为每个状态修改请求验证返回头字段。
  
    XSRF tokens should be unique per user and session, have a large random value generated by a
    cryptographically secure random number generator, and expire.
  
    XSRF令牌应该是对每个用户和session唯一的，它包含一大串随机值，它是由一个加密性安全随机数字生成器生成的，并且会失效。
  
    Angular applications can customize cookie and header names by binding their own
    `CookieXSRFStrategy` value, or implement an entirely custom `XSRFStrategy` by providing a custom
    binding for that type.
  
    Angular应用程序可以自定义cookie和头字段名字，可以通过绑定它们自己的`CookieXSRFStrategy`值，
    也可以通过提供一个自定义类型绑定实现一个完全制定`XSRFStrategy`。
  
    Learn about Cross Site Request Forgery (XSRF) at the Open Web Application Security Project (OWASP)
    [here](https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29) and
    [here](https://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet). This [Stanford University
    paper](https://seclab.stanford.edu/websec/csrf/csrf.pdf) is a rich source of detail.
  
    到开放式Web应用程序安全项目(OWASP)[这里](https://www.owasp.org/index.php/Cross-Site_Request_Forgery_%28CSRF%29)
    和[这里](https://www.owasp.org/index.php/CSRF_Prevention_Cheat_Sheet)学习更多关于跨站请求伪造（XSRF）的知识。
    这个[斯坦福大学论文](https://seclab.stanford.edu/websec/csrf/csrf.pdf)有详尽的细节。
  
  h3#xssi Cross-site Script Inclusion (XSSI)
  
  h3#xssi 跨站脚本包含(XSSI)
  :marked
    Cross-site Script Inclusion, also known as JSON vulnerability, can allow an attacker's website to
    read data from a JSON API. The attack works on older browser by overriding native JavaScript
    object constructors, and then including an API URL using a `<script>` tag.
  
    跨站脚本包含，也被叫做Json漏洞，可以允许一个攻击者的网站从一个JSON API读取数据。攻击者在一个老的浏览器上工作，
    重写原生JavaScript对象构造器，然后在一个API URL中引入一个`<script>`标签。
  
    This attack is only successful if the returned JSON is executable as JavaScript. Servers can
    prevent it by prefixing all JSON responses to make them non-executable, by convention using the
    well-known string `")]}',\n"`.
  
    只有在返回的JSON是像JavaScript一样可以被执行时，这种攻击才有效。在服务端按约定使用著名字符串`")]}',\n"`来前缀所有JSON响应，把它们标记为不可执行，
    可以防止这种攻击，
  
    Angular's `Http` library recognizes this convention and automatically strips the string
    `")]}',\n"` from all responses before further parsing.
  
    Angular的`Http`包识别这个约定，并在进一步解析之前，自动把字符串`")]}',\n"`从所有响应中去掉。
  
    Learn more in the XSSI section of this [Google web security blog
    post](https://security.googleblog.com/2011/05/website-security-for-webmasters.html)
    
    到这个[谷歌Web安全博客文章](https://security.googleblog.com/2011/05/website-security-for-webmasters.html)的XSSI小节学习更多这方面的知识。
  
  .l-main-section
  h2#code-review Auditing Angular Applications
  
  h2#code-review 审计Angular应用程序
  
  :marked
    Angular applications should follow the same security principles as regular web applications, and
    should be audited as such. Angular specific APIs that should be audited in a security review,
    such as the [_bypassSecurityTrust_](#bypass-security-apis) APIs, are marked in the documentation
    as security sensitive.
  
    Angular应用程序应该遵循和常规Web应用程序一样的安全原则并按照这些原则被审计。Angular的一些应该在安全检阅中被审计的特有API，
    比如[_bypassSecurityTrust_](#bypass-security-apis) API，都在文档中被标记为安全性敏感。
  