anchor.diff:    your intended use of the value. Imagine the following template needs to bind a URL to a
     `javascript:alert(...)` call.
   
  +  记住，一个值是否安全依赖于它所在的环境，所以你要为这个值的预定用法选择正确的环境。假设下面的的模版需要绑定URL到`javascript.alert(...)`方法。
  +
   +makeExample('security/ts/app/bypass-security.component.html', 'dangerous-url')(format=".")
   :marked
     Normally, Angular would automatically sanitize the URL and disable the dangerous code. To prevent
     this, we can mark the URL value as a trusted URL using the `bypassSecurityTrustUrl` call:
  +
  +  一般情况下，Angular会自动无毒化这个URL并禁止危险的代码。为了防止这种行为，我们可以调用`bypassSecurityTrustUrl`，来标记这个URL值为一个信任的URL：
   
   +makeExample('security/ts/app/bypass-security.component.ts', 'trust-url')(format=".")
   figure.image-display
  
positive.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`.
  
    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.
  
    XSRF tokens should be unique per user and session, have a large random value generated by a
    cryptographically secure random number generator, and expire.
  
    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.
  
    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.
  
  h3#xssi Cross-site Script Inclusion (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.
  
    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"`.
  
    Angular's `Http` library recognizes this convention and automatically strips the string
    `")]}',\n"` from all responses before further parsing.
  
    Learn more in the XSSI section of this [Google web security blog
    post](https://security.googleblog.com/2011/05/website-security-for-webmasters.html)
  
  .l-main-section
  h2#code-review Auditing Angular Applications
  :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.
  
negative.code:   [Dynamic Forms Cookbook](../cookbook/dynamic-form.html) on how to dynamically construct forms in a
    safe way.
  
    离线模版编译器防止一整套叫做模版注入的漏洞，并能在很大程度上增强应用程序性能。在产品发布时使用离线模板编译器。
    不要动态的生成模版。Angular信任模版代码，所以生成模版，尤其是包含用户数据的模版能规避Angular自带的保护。
    参见[动态表单烹饪书](../cookbook/dynamic-form.html)关于如何安全的动态创建表单。
  
    ### Server side XSS protection
    
    ### 服务器端XSS保护
  
    HTML constructed on the server is vulnerable to injection attacks. When generating server side
    HTML, e.g. for the initial page load of the Angular application, make sure to use a templating
  