Security Best Practices in Angular (Part 1)

This article describes Angular’s built-in protections against common web-application vulnerabilities and attacks.

Photo by Markus Spiske on Unsplash

Angular has been a standard framework for many Business applications owing to its many advantages like easy testing, MVC architecture, security, two-way data binding, modularity, reusability, and many more. I recently started working on Angular and decided that I would read one page of Angular Docs everyday. I was fascinated by how Angular handled security for common attacks like Cross-site scripting (XSS), Cross-site request forgery (CSRF) , Cross-site script inclusion (XSSI). This fascination coupled with the need to share this information is making me write my first Medium article (yay..).

I want to make the article pretty detailed so, I won’t be covering the whole topic in this article as it’s pretty long and I obviously don’t want to bore you to death. So, let’s split up this article into two parts where Part 1 deals with the Prevention of cross-site scripting (XSS) and Part 2 deals with Trusting safe values and HTTP-Level vulnerabilities.

Preventing Cross-Site Scripting (XSS)

Cross-site scripting(XSS) enables attackers to inject malicious code into web pages. Such code can then, for example, steal user data or perform malicious actions. This is one of the most common attacks on the web.

To block XSS attacks, you must prevent malicious code to even enter your DOM (Document Object Model). If attackers can trick you into inserting a <script> tag in the DOM, they can run arbitrary malicious code on your website. This attack isn’t limited to only <script> tags but many elements and properties in the DOM allow code execution, for example,
<img onerror="..."> and <a href="javascript:...">

Angular’s cross-site scripting security model

Angular treats all values as untrusted by default to block XSS bugs. 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.

Sanitization and security contexts

Sanitization is the inspection of an untrusted value, turning it into a value that’s safe to insert into the DOM. In many cases, sanitization doesn’t change a value at all. Sanitization actually depends on context: a value that’s harmless in CSS can be potentially dangerous in a URL.

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 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 HTML,styles, and URLs; sanitizing resources URLs isn’t possible because they contain arbitrary code. Angular does print a console warning when it has to change value during sanitization.

Now, lets look at an example to understand what sanitization does and how it behaves in different two scenarios.

The following template 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.

src/app/inner-html-binding.component.html

Interpolated content is always escaped i.e HTML isn’t interpreted and the browser displays angle bracket in the element’s text content.

For the HTML to be interpreted, bind it to an HTML property such as innerHTML. But binding a value that an attacker might control into innerHTML is one of the main causes of XSS vulnerability. For example, code contained in <script> tag is executed:

src/app/inner-html-binding.component.ts (class)

Angular recognises the value as unsafe and automatically sanitizes it, which removes the <script> tag but keeps safe content such as the <b> element.

Angular Sanitization Example

Let’s look at some caveats in Angular Sanitization:

1. Direct use of DOM APIs and explicit sanitization calls:
   The built in browser DOM APIs don’t automatically protect you from security vulnerabilities, if you interact with other libraries that manipulate the DOM, you likely won’t have the same automatic sanitization as with Angular interpolations. In unavoidable cases where we need user input then we can use built-in Angular sanitization functions to sanitize our input.
2. Content Security Policy:
   Content Security Policy (CSP) is a defense-in-depth technique to prevent XSS. To enable CSP, configure your web server to return an appropriate Content-Security Policy HTTP header.
3. Server-side XSS protection:
   HTML constructed on the server is vulnerable to injection attacks. To prevent this, use a templating language that automatically escapes values to prevent XSS vulnerabilites on the server.

Thanks guys, this is it for Part-1 of the Security Best Practices. I hope you guys learnt something new today. For the next part I will be going through how we can bypass the automatic sanitization behaviour and more.
Please let me know how the blog is in the comments and of course you can ask questions if you didn’t grasp something. I would love to help.