As more and more enterprises undergo digital transformation given the need of the time, the IT infrastructure gets vulnerable to security threats. Technologies evolve, but so do the attack techniques and methods. Vulnerabilities identified in your IT stack are highly likely to be exploited if enterprises do not employ proper security measures throughout the SDLC.
Increasing malicious attacks today have pushed businesses to switch from DevOps to DevSecOps. But best security practices executed during the SDLC- right from the beginning to end doesn’t have to compromise with faster release times.
Now, Angular comprises built-in security protocols to protect against common attacks and web-app vulnerabilities. Mostly, malicious user input is what eventually exposes your web application to cross-site scripting (XSS) vulnerabilities. So, how do you protect your Angular code?
In this post, we are going to see 5 best security practices you can implement to secure your Angular code or Angular applications, without interrupting the workflows.
Let’s begin:
What is Angular?
Angular is a framework with which you can seamlessly build SPA (single-page applications) via TypeScript. Developed by Microsoft, TypeScript is an open-source language, which is also an absolute superset of JavaScript. There are myriads of TypeScript libraries in Angular with their core functionality; plus you can add more libraries if you’re looking for add-on features.
Back in 2010, Google developed AngularJS- also referred to as Angular1. It became very popular but had prominent competitors such as React and Vue.
Later in 2014, Google fully shifted from JavaScript to TypeScript and released Angular 2- a complete transformation of AngularJS. Everything was transformed- right from its framework, approach towards data to programming language. The main advantage of TypeScript is how it offers good static typing features. Angular 2 and all the versions after it are known as Angular or Angular 2+. As of May 2022, Angular 2+, written in TypeScript, is at version 13.
5 Best Ways to Protect your Angular Code:
Here are the best practices to secure applications running on Angular code. These steps will help you protect against malicious attacks such as cross-site request forgery (CSRF) and cross-site scripting (XSS). These may seem low-key at first, but eventually lead to a larger and persistent threat to your infrastructure.
- Protection against XSS (Cross-site Scripting):
An XSS (cross-site scripting) is a type of vulnerability attack that involves injecting scripts into your packages’ Document Object Model (DOM). With this, the attackers can have access to data to steal confidential information or user data. To prevent this, enterprises must sanitize their unreliable inputs across the entire stack:
- Attributes (binding values)
- HTML
- Style (CSS)
- Resources
Make sure to always use DomSanitizer to convert suspicious values into trustable values provided by an external user. To achieve a secure value, bind the [innerHtml] attribute with safeValue and push the HTML string through the service method. This ensures the data in its context is interpreted as HTML and is sanitized, thus discarding all untrusted tags. This will prevent attackers from running any malicious cross-site scripting code.
import { Component, OnInit } from '@angular/core';
import { MyService } from './data.service';
import { DomSanitizer, SafeHtml } from '@angular/platform-browser';
@Component({
selector: 'app-root',
template: `<div [innerHtml] = "safeValue"></div>`,
providers: [MyService]
})
export class MyComponent implements OnInit {
safeValue: SafeHtml;
constructor(private secure: MyService) {
this.safeValue = this.secure.getSafeHtml("<h1>Sanitization Success</h1>");
}
ngOnInit() {
}
}
- No Customization to Angular Libraries:
Never customize Angular libraries as per your liking, as this means you’ll heavily rely on that particular Angular version. By the same token, it will be hard for you to upgrade to the latest Angular versions, thus causing you to blink at important security patches and features.
If you are still willing to customize Angular libraries, make sure to share it with the Angular’s community through a pull request. Other developers may analyze your modifications and add it to the next version release.
- Avoid suspicious Angular APIs
In the Angular documentation, some of the API endpoints are marked as “Security Risk”, for example ElementRef. This API may allow attackers to access DOM on your webpages and expose your application to XSS attack vulnerability. Avoid using this API, and if you absolutely have to, make sure to only do it when it is an absolute necessity.
Alternatively, Angular offers you with its native data binding and templating features in place of ElementRef.
- HTTP-Level Vulnerabilities
Angular comes with built-in protection features to protect your code against CSRF (cross-site request forgery) and XSSI (cross-site script inclusion). Angular’s HttpClient helps you prevent attacks by integrating a resistant server with your application.
- CSRF (cross-site request forgery): it is a type of attack where a trusted user sends suspicious, unauthorized commands. To mitigate such risks, send an authentication token added into a cookie via the application server. The client will read it and amongst consecutive requests will insert a custom request header using the same token. Due to this, it becomes easier to reject an attacker’s request, as they do not have a token.
Angular also offers HttpClient with which you get built-in authentication support to use tokens on the client-side.
- Cross-site Script Inclusion (XSSI): XXSI is a type of malicious attack through which an attacker gets access to your application’s JSON API. Commonly, old browsers have this vulnerability and attackers exploit it, thereby abrogating native JavaScript object constructors. With this, it can use a <script> tag to provide an API URL. To mitigate this attack, the server can change all JSON responses to make them non-executable.
Angular uses string interpolation ({{ }}) to securely encode malicious characters in template expression and avoid suspicious HTML or CSS expressions. By default, Angular treats all data as untrusted and it performs best security practices such as ‘output encoding’ on all libraries for any HTML-level text.
- Don’t use templates created by concatenating user input
Another best security practice for Angular is to NOT concatenate any user input as a string into your template. If you witness this in codebase, it is highly recommended to refactor or sanitize the potential user input.
Here’s an example of what you should AVOID at all costs:
If you look at the line 20, there’s an odd string potentialUserInput to template concatenation. Its value is likely to be an untrusted, malicious expression originating from an unknown source. Watch out for these in your codebase.
To mitigate this risk, you can use the offline template compiler to prevent all template injection vulnerabilities.
Final Words
Angular is a very popular and rapidly evolving framework that helps you create powerful web and mobile applications. Developers and security teams equally need to pay attention to code’s security and ensure best practices are employed throughout the SDLC.
Simply writing a secure code right from the beginning will protect it from bugs, errors and exploitation. Indeed, there will be risks along the way, but having a mindset to implement best security practices for Angular code will make it easier to reduce MTTR and seamlessly release security patches.
Also Read: Rescue Yourself From A Phishing Malware
