Programming securely is the most happening debated issue these days. The web developers/designers should be always on toes to act on the cyber-attacks and should be aware of expecting the security issues when building a web application. No matter, how robust the security walls are built; there is always a threat coming on its way behind the screens.

In such scenarios, AngularJS has been developed to take up the responsibility of addressing the major security vulnerabilities that can be expected on the Client side. On the other hand, it is not assured that AngularJS applications are impervious to security vulnerabilities.

This blog helps you to understand better about the best practices we ought to follow as a primary concern while developing an AngularJS application so that we constrain the measure of security issues we may expect.

Try using the latest AngularJS version as long as it is possible?

• We all know the importance of staying updated and using the latest version of any software library and AngularJS is no different.
• It is always recommended to track the CHANGELOG and be aware of the bugs/vulnerabilities reported in the current version and perform a deep dive of the report to understand how it affects your application.
• At the same time, you should always be ready to upgrade your system instantly when a secure and stable version/patch is released.
• Security team at AngularJS strongly recommends not to modify the copy of AngularJS rather encourages them to share their Angular improvements with the community and make a pull request.

Angular Security Model to safeguard Cross-Site Scripting (XSS) attacks

• By default, Angular treats all the user-inputs as untrusted when they are inserted into the DOM from a template, via property, attribute, style, class binding, or interpolation and hence it sanitizes and escapes those values but by turning off the auto sanitization by Angular, we expose our application to high security risks which is strongly not recommended.
• Applications must restrict the malicious inputs that an attacker can inject/embed into the source code of a template and hence recommends to never generate template source code by concatenating user input and templates and rather use an offline template compiler (as known as AOT-COMPILER) to safeguard against the Template Injection attacks.
• If you are using the Angular CLI, it just takes 2 commands to enable AOT:

‍Sanitization in AngularJS and providing security context

• Angular sanitizes untrusted values for HTML, styles, and URLs but sanitizing the resource URLs (for example, in <script src>) is not possible as they contain arbitrary code and hence, it is recommended to implement a whitelist for all the resource URLs.
• Angular recommends the programmers to avoid the direct interaction with the DOM and encourages using Angular templates wherever possible and for situations which are unavoidable, Angular also suggests to prefer the built-in Angular sanitization functions (sanitize method and the appropriate Security Context).

Below mentioned is the code declaring the sanitization providers in BrowserModule:

The skeleton of the class looks like this:

Angular proposes to enable the Content Security Policy (CSP) by configuring the web server to return an appropriate Content-Security-Policy HTTP header which safeguards against the XSS attacks.

Secure the application from Server-Side XSS attacks

• HTML/templates constructed on the server side are vulnerable to injection attacks and hence, Angular recommends to use a templating language that automatically escapes/sanitizes the user-inputs/values to safeguard against the Server-Side XSS attacks

Be careful while trusting safe values

• Angular has a built-in support which provides safeguard against the two common HTTP vulnerabilities, Cross-Site Request Forgery (CSRF or XSRF) and Cross-Site Script Inclusion (XSSI) which are mostly taken care on the server side. But, Angular guides the helpers to make the integration on the client side easier and recommends its implementation in the application to prevent such vulnerabilities.

Example implementation for trusting values using DomSanitizer:

Angular's HttpClient to prevent Cross-site script inclusion (XSSI)

• Cross-Site Script Inclusion, also known as JSON vulnerability, allows the attacker to read data from a JSON API on older browsers by overriding native JavaScript object constructors, and then including an API URL using a  <script>  tag.
• Angular's HttpClient library allows the servers to convert the JSON responses into non-executable by appending the string ")]}',\n". While parsing it recognizes this convention and automatically strips the string ")]}',\n" and thereby mitigates against the XSSI attacks.

Regular Auditing of Angular applications

• Angular applications must be audited regularly to make sure that all the security principles are strictly adhered, and the application is safe and secure for the customer’s use, prior to a production release.

Credit: Harshal - Security Researcher