Security

This section 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 this user?) or authorization (What can this user do?).

For more information about the attacks and mitigations described below, see OWASP Guide Project.

Contents:

• Reporting vulnerabilities.
• Best practices.
• Preventing cross-site scripting (XSS).
• Trusting safe values.
• HTTP-Level vulnerabilities.
• Auditing Angular applications.

Try the live example of the code shown in this page.

Reporting vulnerabilities

Email us at security@angular.io to report vulnerabilities in Angular itself.

For more information about how Google handles security issues, see Google's security philosophy.

Best practices

• Keep current with the latest Angular library releases. We regularly update our Angular libraries, and these updates may fix security defects discovered in previous versions. Check the Angular change log for security-related updates.

• Don't modify your copy of Angular. Private, customized versions of Angular tend to fall behind the current version and may not include important security fixes and enhancements. Instead, share your Angular improvements with the community and make a pull request.

• Avoid Angular APIs marked in the documentation as “Security Risk.”

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 (in particular, their login data) or perform actions impersonating the user. This is one of the most common attacks on the web.

To block XSS attacks, you must prevent malicious code from entering the DOM (Document Object Model). For example, if an attacker can trick you into inserting a <script> tag in the DOM, they can run arbitrary code on your website. The attack is not limited to <script> tags—many elements and properties in the DOM allow code execution, for example, <img onerror="..."> and <a href="javascript:...">. If attacker-controlled data enters the DOM, expect security vulnerabilities.

Angular’s cross-site scripting security model

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

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. This means that applications must prevent values that an attacker can control 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 is an effective way to prevent these vulnerabilities, also known as template injection.

Sanitization and security contexts

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

Angular defines four security contexts—HTML, style, URL, and resource URL:

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

Angular sanitizes untrusted values for the first three items; sanitizing resource URLs is not possible because they contain arbitrary code. In development mode, Angular prints a console warning when it has to change a value during sanitization.

Sanitization example

The template below 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:

<h3>Binding innerHTML</h3>
<p>Bound value:</p>
<p class="e2e-inner-html-interpolated">{{htmlSnippet}}</p>
<p>Result of binding to innerHTML:</p>
<p class="e2e-inner-html-bound" [innerHTML]="htmlSnippet"></p>

Interpolated content is always escaped—the HTML is not interpreted, and the browser displays angle brackets in the element's text content.

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

export class InnerHtmlBindingComponent {
  // For example, a user/attacker-controlled value from a URL.
  htmlSnippet = 'Template <script>alert("0wned")</script> <b>Syntax</b>';
}

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

Avoid direct use of the DOM APIs

The built-in browser DOM APIs do not automatically protect you from security vulnerabilities. For example, document, the node available through ElementRef, and many third-party APIs contain unsafe methods. Avoid directly interacting with the DOM and instead use Angular templates where possible.

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.

Use the offline template compiler

The offline template compiler prevents a whole class of vulnerabilities called template injection, and also greatly improves application performance. Use the offline template compiler in production deployments; do not dynamically generate templates. Angular trusts template code, so generating templates, in particular templates containing user data, circumvents Angular's built-in protections. For information about how to dynamically construct forms in a safe way, see Dynamic Forms Cookbook.

Server-side XSS protection

HTML constructed on the server is vulnerable to injection attacks. Injecting template code into an Angular application is the same as injecting executable code into the application: it gives the attacker full control over the application. To prevent this, use a templating language that automatically escapes values to prevent XSS vulnerabilities on the server. Do not generate Angular templates on the server side using a templating language; doing this carries a high risk of introducing template-injection vulnerabilities.

Trusting safe values

Sometimes applications genuinely need to include executable code, display an <iframe> from some URL, or construct potentially dangerous URLs. To prevent automatic sanitization in any of these situations, you can tell Angular that you inspected a value, checked how it was generated, and made sure it will always be secure. But be careful! If you trust a value that might be malicious, you are introducing a security vulnerability into your application. If in doubt, find a professional security reviewer.

You can mark a value as trusted by injecting DomSanitizer and calling one of the following methods:

• bypassSecurityTrustHtml
• bypassSecurityTrustScript
• bypassSecurityTrustStyle
• bypassSecurityTrustUrl
• bypassSecurityTrustResourceUrl

Remember, whether a value is safe depends on context, so you need to choose the right context for your intended use of the value. Imagine that the following template needs to bind a URL to a javascript:alert(...) call:

<h4>An untrusted URL:</h4>
<p><a class="e2e-dangerous-url" [href]="dangerousUrl">Click me</a></p>
<h4>A trusted URL:</h4>
<p><a class="e2e-trusted-url" [href]="trustedUrl">Click me</a></p>

Normally, Angular automatically sanitizes the URL, disables the dangerous code, and in development mode, logs this action to the console. To prevent this, you can mark the URL value as a trusted URL using the bypassSecurityTrustUrl call:

constructor(private sanitizer: DomSanitizer) {
  // javascript: URLs are dangerous if attacker controlled.
  // Angular sanitizes them in data binding, but you can
  // explicitly tell Angular to trust this value:
  this.dangerousUrl = 'javascript:alert("Hi there")';
  this.trustedUrl = sanitizer.bypassSecurityTrustUrl(this.dangerousUrl);

If you need to convert user input into a trusted value, use a controller method. The template below allows users to enter a YouTube video ID and load the corresponding video in an <iframe>. The <iframe src> attribute is a resource URL security context, because an untrusted source can, for example, smuggle in file downloads that unsuspecting users could execute. So call a method on the controller to construct a trusted video URL, that causes Angular to then allow binding into <iframe src>:

<h4>Resource URL:</h4>
<p><label>Showing: <input (input)="updateVideoUrl($event.target.value)"></label></p>
<p>Trusted:</p>
<iframe class="e2e-iframe-trusted-src" width="640" height="390" [src]="videoUrl"></iframe>
<p>Untrusted:</p>
<iframe class="e2e-iframe-untrusted-src" width="640" height="390" [src]="dangerousVideoUrl"></iframe>

updateVideoUrl(id: string) {
  // Appending an ID to a YouTube URL is safe.
  // Always make sure to construct SafeValue objects as
  // close as possible to the input data so
  // that it's easier to check if the value is safe.
  this.dangerousVideoUrl = 'https://www.youtube.com/embed/' + id;
  this.videoUrl =
      this.sanitizer.bypassSecurityTrustResourceUrl(this.dangerousVideoUrl);
}

HTTP-level vulnerabilities

Angular has built-in support to help prevent two common HTTP vulnerabilities, cross-site request forgery (CSRF or XSRF) and cross-site script inclusion (XSSI). Both of these must be mitigated primarily on the server side, but Angular ships helpers to make integration on the client side easier.

Cross-site request forgery

In a cross-site request forgery, an attacker tricks the user into visiting a different page and has them, for example, submit a form that sends a request to your application's web server. If the user is logged into your application, the browser will send authentication cookies, and the attacker could—for example—cause a bank transfer in the user's name with the right request.

To prevent this, your application must ensure that user requests originate in your own application, not on a different site. A common technique is that the server sends a randomly generated authentication token in a cookie, often with the name XSRF-TOKEN. Only the website on which cookies are set can read the cookies, so only your own application can read this token. On each API request, the server then validates the client by checking that the token is sent back, usually in an HTTP header called X-XSRF-TOKEN.

The Angular http client has built-in support for this technique. The default CookieXSRFStrategy looks for a cookie called XSRF-TOKEN and sets an HTTP request header named X-XSRF-TOKEN with the value of that cookie on every request. The server must set the XSRF-TOKEN cookie and validate the response header for each state-modifying request.

CSRF tokens should be unique per user and session, have a large random value generated by a cryptographically secure random number generator, and expire.

Angular applications can customize cookie and header names by binding their own CookieXSRFStrategy value or implement an entirely custom XSRFStrategy through providing a custom binding for that type by adding either of the following to your providers list:

{ provide: XSRFStrategy, useValue: new CookieXSRFStrategy('myCookieName', 'My-Header-Name')}
{ provide: XSRFStrategy, useClass: MyXSRFStrategy}

For information about CSRF at the Open Web Application Security Project (OWASP) see Cross-Site Request Forgery (CSRF) and Cross-Site Request Forgery (CSRF) Prevention Cheat Sheet. The Stanford University paper Robust Defenses for Cross-Site Request Forgery is also a rich source of detail.

Cross-site script inclusion (XSSI)

Cross-site script inclusion, also known as JSON vulnerability, can allow an attacker's website to read data from a JSON API. The attack works on older browsers by overriding native JavaScript object constructors, and then including an API URL using a <script> tag.

This attack is only successful if the returned JSON is executable as JavaScript. Servers can prevent an attack by prefixing all JSON responses to make them non-executable, by convention, using the well-known string ")]}',\n".

Angular's Http library recognizes this convention and automatically strips the string ")]}',\n" from all responses before further parsing.

For more information, see the XSSI section of this Google web security blog post.

Auditing angular applications

Angular applications must follow the same security principles as regular web applications, and must be audited as such. Angular-specific APIs that should be audited in a security review, such as the bypassSecurityTrust methods, are marked in the documentation as security sensitive.