anchor.diff:      Sometimes applications genuinely need to include executable code, display an `<iframe>` from some
       URL, or construct potentially dangerous URLs. To prevent automatic sanitization in any of these 
       situations, you can tell Angular that you inspected a value, checked how it was generated, and made 
  -    sure it will always be secure. But **be careful**! If you trust a value that might be malicious, you 
  +    sure it will always be secure. But *be careful*. If you trust a value that might be malicious, you 
       are introducing a security vulnerability into your application. If in doubt, find a professional 
       security reviewer.
   
  -    You can mark a value as trusted by injecting `DomSanitizer` and calling one of the
  +    To mark a value as trusted, inject `DomSanitizer` and call one of the
       following methods:
   
       * `bypassSecurityTrustHtml`
  
positive.code:   important security fixes and enhancements. Instead, share your Angular improvements with the
    community and make a pull request.
  
    * **Avoid Angular APIs marked in the documentation as “[_Security Risk_](#bypass-security-apis).”**
  
  .l-main-section
  h2#xss Preventing cross-site scripting (XSS)
  :marked
    [Cross-site scripting (XSS)](https://en.wikipedia.org/wiki/Cross-site_scripting) enables attackers
    to inject malicious code into web pages. Such code can then, for example, steal user data (in
    particular, their login data) or perform actions impersonating the user. This is one of the most
    common attacks on the web.
  
    To block XSS attacks, you must prevent malicious code from entering the DOM (Document Object Model). For example, if an
    attacker can trick you into inserting a `<script>` tag in the DOM, they can run arbitrary code on
    your website. The attack is not limited to `<script>` tags&mdash;many elements and properties in the
    DOM allow code execution, for example, `<img onerror="...">` and `<a href="javascript:...">`. If
    attacker-controlled data enters the DOM, expect security vulnerabilities.
  
    ### Angular’s cross-site scripting security model
  
    To systematically block XSS bugs, Angular treats all values as untrusted by default. When a value
    is inserted into the DOM from a template, via property, attribute, style, class binding, or interpolation, Angular sanitizes and escapes untrusted values.
  
    _Angular templates are the same as executable code_: HTML, attributes, and binding expressions
    (but not the values bound!) in templates are trusted to be safe. This means that applications must
    prevent values that an attacker can control from ever making it into the source code of a
    template. Never generate template source code by concatenating user input and templates! Using
    the [offline template compiler](#offline-template-compiler) is an effective way to prevent these
    vulnerabilities, also known as _template injection_.
  
    ### Sanitization and security contexts
  
    _Sanitization_ is the inspection of an untrusted value, turning it into a value that is safe to insert into
    the DOM. In many cases, sanitization does not change a value at all. Sanitization depends on context:
    a value that is harmless in CSS is potentially dangerous in a URL.
  
    Angular defines four security contexts&mdash;HTML, style, URL, and resource URL:
  
    * **HTML** is used when interpreting a value as HTML, for example, when binding to `innerHtml`
    * **Style** is used when binding CSS into the `style` property
    * **URL** is used for URL properties such as `<a href>`
    * **Resource URL** is a URL that will be loaded and executed as code, for example, in `<script src>`
  
    Angular sanitizes untrusted values for the first three items; sanitizing resource URLs is not
    possible because they contain arbitrary code. In development mode, Angular prints a console warning
    when it has to change a value during sanitization.
  
    ### Sanitization example
  
    The template below binds the value of `htmlSnippet`, once by interpolating it into an element's
    content, and once by binding it to the `innerHTML` property of an element:
  
  +makeExample('src/app/inner-html-binding.component.html')
  
  :marked
    Interpolated content is always escaped&mdash;the HTML is not interpreted, and the browser displays
    angle brackets in the element's text content.
  
    For the HTML to be interpreted, you must bind it to an HTML property such as `innerHTML`. But binding
    a value that an attacker might control into `innerHTML` normally causes an XSS
    vulnerability. For example, code contained in a `<script>` tag is executed:
  
  
negative.code:     includes a matching `XSRF-TOKEN` cookie and `X-XSRF-TOKEN` header.
  
      XSRF/CSRF tokens should be unique per user and session, have a large random value generated by a
      cryptographically secure random number generator, and expire in a day or two.
  
      Your server may use a different cookie or header name for this purpose.
      An Angular application can customize cookie and header names by providing its own `CookieXSRFStrategy` values.
  