Improve this DocSecurity

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 [email protected] to report any potential security issues in AngularJS.

Please keep in mind the points below about Angular'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 Angular standards (such as modifying Angular'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.

Expression Sandboxing

AngularJS's expressions are sandboxed not for security reasons, but instead to maintain a proper separation of application responsibilities. For example, access to window is disallowed because it makes it easy to introduce brittle global state into your application.

However, this sandbox is not intended to stop attackers who can edit the template before it's processed by Angular. It may be possible to run arbitrary JavaScript inside double-curly bindings if an attacker can modify them.

But if an attacker can change arbitrary HTML templates, there's nothing stopping them from doing:

<script>somethingEvil();</script>

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

For instance:

Do not mix client and server templates
Do not use user input to generate templates dynamically
Do not run user input through $scope.$eval
Consider using CSP (but don't rely only on CSP)

Mixing client-side and server-side templates

In general, we recommend against this because it can create unintended XSS vectors.

However, it's ok to mix server-side templating in the bootstrap template (index.html) as long as user input cannot be used on the server to output html that would then be processed by Angular in a way that would allow for arbitrary code execution.

For instance, you can use server-side templating to dynamically generate CSS, URLs, etc, but not for generating templates that are bootstrapped/compiled by Angular.

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. Angular 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". Angular 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, like in our Yahoo! finance example, 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 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 Angular 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.