Angular Security Best Practices

Following are the best practices:

  1. Use Interpolation to safeguard from XSS

    Use interpolation ({{  }}) to safely encode potentially dangerous characters and escape untrusted HTML or CSS expressions within a template expression.  Angular, much like React and Vue.js, takes on a security-by-default approach in the way it handles string interpolation in the browser. By default, all data is treated as unsafe and untrusted, and hence all these libraries, and other modern view libraries, follow the best practice of performing output encoding by default for any text in an HTML context. 
    It is strongly recommended to follow the Angular way by using its built-in curly braces string interpolation in order to escape any malicious user input that could put your web application at risk and may potentially lead to exposing your web application to Cross-site Scripting (XSS) vulnerabilities.

  2. Use innerHTML with caution    

    If you must dynamically add HTML to a component, bind its generation to [innerHTML]. This ensures data will be interpreted as HTML in its context and sanitized, removing all unsafe tags and hence preventing it from executing any malicious cross-site scripting code. Notice that the action of sanitizing is not the same as encoding.

    Difference between sanitization and output encoding:

    In output encoding, strings are replaced with their text representation, which can be mapped to a certain HTML tag. For example, if an input such as script is parsed, Angular can choose to display that text by encoding the special angle brackets notation, a standard for many other libraries and frameworks implementing security best practices. In order to do so, it performs  a mapping of what is known as HTML entities encoding and writes to the DOM the following text: script. The browser then interprets the context and outputs a script tag.

    Unlike output encoding, the action of sanitization or filtering takes a more proactive approach of detecting unsafe characters and removing them from the text that is then written to the DOM. 

    Context becomes a deciding factor of output encoding and sanitization as it has a direct influence on the way to properly perform the action.

    Refer to the Angular documentation to learn more about security contexts.

    Angular defines the following security contexts:

    • 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>.

  3. Never generate templates by concatenating user input

    Never concatenate any potentially user provided input as a string to a template.
    For some use cases, deriving is the need to concatenate templates rather than properly using string interpolation or the recommended component composition in an Angular application. In case of any such bad practice in a codebase, sanitize or refactor, to all possible extent to the provided input.

    Here are the things to avoid:

    Angular security issue

    Angular Security Best Practice: Never use templates generated by concatenating user input.

    Pay careful attention at the unconventional string to template concatenation in line 20. potentialUserInput ‘s value may be a malicious expression of unknown or untrusted origin. This is an example of a bad practice.

    Following is a more complete image to try  in the Angular playground, showing how user input isn’t handled safely if concatenated to the template:

    Angular security best practice

    Angular Security best practice in action: Never use templates generated by concatenating user input.

    Here are some of the Angular security Guide official recommendation states:

    “Never generate template source code by concatenating user input and templates. To prevent these vulnerabilities, use the offline template compiler, also known as template injection.”

    – Angular security guide

    Angular recommends using its Ahead of Time compiler to compile templates offline. This helps you entirely avoid the plethora of template injection vulnerabilities:

    ng build --aot

    ng serve --aot

    Observe that in the latest versions of Angular—Angular v9 and higher—compiling with Ivy, ahead of time compilation is set to true by default, preventing template injection:

    Copy

    json

     
    {
      "projects": {
        "my-existing-project": {
          "architect": {
            "build": {
              "options": {
                ...
                "aot": true,
              }
            }
          }
        }
      }
    }

  4. Never use native DOM APIs to interact with HTML elements

    Never use native DOM APIs to interact with HTML elements on the page. Avoid direct DOM manipulation and use Angular template mechanisms, and Angular’s own APIs to manipulate the DOM instead.
    As a general guideline, avoid the following:

    •  node.appendChild(); 

    • using the document object methods to interact with the page

    • using jQuery APIs

      There are native Angular APIs that allow the same type of direct DOM manipulation that we’re advising against—for example, the ElementRef API. Angular ElementRef introduces security issues when used to gain access to a direct DOM node and perform manipulations at that point.
      This and other interactions outside of the Angular set of APIs could potentially lead to security vulnerabilities.

  5. Avoid template engines on server-side templates

    Avoid 3rd party template engines to create or add templates data on Angular server-side rendered applications.

    If you’ve been using Node.js to build web applications, you have probably used a template engine such as EJS, Pug, Handlebars, or one of their alternatives at some point in time. They are used to manage  server-side rendered templates for the view layer and may include partials or layouts composites, and other sorts of features that help dynamically generate a view. 

    However, implementing these template engine mechanisms in a configuration of Angular’s server-side rendered application could lead to potential injection of malicious code into a template. That happens because data injected is external to the scope of the Angular API and cannot be sanitized, posing the same risks as template string concatenation.

  6. Scan your Angular project for components which introduce security vulnerabilities

    Always scan your Angular project open-source dependencies and Angular components for security vulnerabilities. When you use third-party libraries, like Angular and its ecosystem of modules or components, ensure that the security vulnerabilities affecting the core Angular library, and security vulnerabilities in the third-party Angular modules you are importing and using in your project.

Ensure to follow Using components with known vulnerabilities as part of the OWASP Top 10 web security risk.