anchor.diff:  
     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.
  +  binding for that type, by adding
  +  `provide(XSRFStrategy, {useValue: new CookieXSRFStrategy('myCookieName', 'My-Header-Name')})` or
  +  `provide(XSRFStrategy, {useClass: MyXSRFStrategy})` to your providers list.
   
     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
  
positive.code: 
    ### Server side XSS protection
  
    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
    language that automatically escapes values to prevent XSS vulnerabilities on the server. Do not
    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
  
negative.code: :marked
    If we need to convert user input into a trusted value, it can be convenient to do so in a
    controller method. The template below allows users to enter a YouTube video ID, and load the
    corresponding video in an `<iframe>`. The `<iframe src>` attribute is a resource URL security
    context, because an untrusted source can e.g. smuggle in file downloads that unsuspecting users
    would execute. So we call a method on the controller to construct a trusted video URL, which
    Angular then allows binding into `<iframe src>`.
  
  +makeExample('security/ts/app/bypass-security.component.html', 'iframe-videoid')(format=".")
  +makeExample('security/ts/app/bypass-security.component.ts', 'trust-video-url')(format=".")
  