anchor.diff:  block includes
     include ../_util-fns
   :marked
  +  # Security
     Web application security has many aspects. This documentation describes Angular's built in
     protections against common web application vulnerabilities and attacks, such as Cross Site
     Scripting Attacks. It does not cover application level security, such as authentication (_Who is
  
positive.code: 
    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
  
negative.code:   is inserted into the DOM from a template, via property, attribute, style, or class binding, or via
    interpolation, Angular will sanitize and escape 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. That means applications must
    prevent potentially attacker controlled values 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 inspects an untrusted value and turns it into a value that is safe to insert into
  