Security

This document explains some of AngularJS's security features and best practices that you should keep in mind as you build your application.

Reporting a security issue

Email us at security@angularjs.org to report any potential security issues in AngularJS.

Please keep in mind the points below about AngularJS's expression language.

Use the latest AngularJS possible

Like any software library, it is critical to keep AngularJS up to date. Please track the CHANGELOG and make sure you are aware of upcoming security patches and other updates.

Be ready to update rapidly when new security-centric patches are available.

Those that stray from AngularJS standards (such as modifying AngularJS's core) may have difficulty updating, so keeping to AngularJS standards is not just a functionality issue, it's also critical in order to facilitate rapid security updates.

AngularJS Templates and Expressions

If an attacker has access to control AngularJS templates or expressions, they can exploit an AngularJS application via an XSS attack, regardless of the version.

There are a number of ways that templates and expressions can be controlled:

• Generating AngularJS templates on the server containing user-provided content. This is the most common pitfall where you are generating HTML via some server-side engine such as PHP, Java or ASP.NET.
• Passing an expression generated from user-provided content in calls to the following methods on a scope:
  • $watch(userContent, ...)
  • $watchGroup(userContent, ...)
  • $watchCollection(userContent, ...)
  • $eval(userContent)
  • $evalAsync(userContent)
  • $apply(userContent)
  • $applyAsync(userContent)
• Passing an expression generated from user-provided content in calls to services that parse expressions:
  • $compile(userContent)
  • $parse(userContent)
  • $interpolate(userContent)
• Passing an expression generated from user provided content as a predicate to orderBy pipe: {{ value | orderBy : userContent }}

Sandbox removal

Each version of AngularJS 1 up to, but not including 1.6, contained an expression sandbox, which reduced the surface area of the vulnerability but never removed it. In AngularJS 1.6 we removed this sandbox as developers kept relying upon it as a security feature even though it was always possible to access arbitrary JavaScript code if one could control the AngularJS templates or expressions of applications.

Control of the AngularJS templates makes applications vulnerable even if there was a completely secure sandbox:

• https://ryhanson.com/stealing-session-tokens-on-plunker-with-an-angular-expression-injection/ in this blog post the author shows a (now closed) vulnerability in the Plunker application due to server-side rendering inside an AngularJS template.
• https://ryhanson.com/angular-expression-injection-walkthrough/ in this blog post the author describes an attack, which does not rely upon an expression sandbox bypass, that can be made because the sample application is rendering a template on the server that contains user entered content.

It's best to design your application in such a way that users cannot change client-side templates.

• Do not mix client and server templates
• Do not use user input to generate templates dynamically
• Do not run user input through $scope.$eval (or any of the other expression parsing functions listed above)
• Consider using CSP (but don't rely only on CSP)

You can use suitably sanitized server-side templating to dynamically generate CSS, URLs, etc, but not for generating templates that are bootstrapped/compiled by AngularJS.

If you must continue to allow user-provided content in an AngularJS template then the safest option is to ensure that it is only present in the part of the template that is made inert via the ngNonBindable directive.

HTTP Requests

Whenever your application makes requests to a server there are potential security issues that need to be blocked. Both server and the client must cooperate in order to eliminate these threats. AngularJS comes pre-configured with strategies that address these issues, but for this to work backend server cooperation is required.

Cross Site Request Forgery (XSRF/CSRF)

Protection from XSRF is provided by using the double-submit cookie defense pattern. For more information please visit XSRF protection.

JSON Hijacking Protection

Protection from JSON Hijacking is provided if the server prefixes all JSON requests with following string ")]}',\n". AngularJS will automatically strip the prefix before processing it as JSON. For more information please visit JSON Hijacking Protection.

Bear in mind that calling $http.jsonp gives the remote server (and, if the request is not secured, any Man-in-the-Middle attackers) instant remote code execution in your application: the result of these requests is handed off to the browser as a regular <script> tag.

Strict Contextual Escaping

Strict Contextual Escaping (SCE) is a mode in which AngularJS requires bindings in certain contexts to require a value that is marked as safe to use for that context.

This mode is implemented by the $sce service and various core directives.

One example of such a context is rendering arbitrary content via the ngBindHtml directive. If the content is provided by a user there is a chance of Cross Site Scripting (XSS) attacks. The ngBindHtml directive will not render content that is not marked as safe by $sce. The ngSanitize module can be used to clean such user provided content and mark the content as safe.

Be aware that marking untrusted data as safe via calls to $sce.trustAsHtml, etc is dangerous and will lead to Cross Site Scripting exploits.

For more information please visit $sce and $sanitize.

Using Local Caches

There are various places that the browser can store (or cache) data. Within AngularJS there are objects created by the $cacheFactory. These objects, such as $templateCache are used to store and retrieve data, primarily used by $http and the script directive to cache templates and other data.

Similarly the browser itself offers localStorage and sessionStorage objects for caching data.

Attackers with local access can retrieve sensitive data from this cache even when users are not authenticated.

For instance in a long running Single Page Application (SPA), one user may "log out", but then another user may access the application without refreshing, in which case all the cached data is still available.

For more information please visit Web Storage Security.

See also

• Content Security Policy