All you need to know about AngularJS Security

Web applications are prone to a number of vulnerabilities, which, if left unaddressed, can be exploited to compromise application processes and data. The OWASP Top 10 puts together the most critical web security risks that are highly prevalent in poorly developed applications.


In the context of AngularJS Security, applications can be secured in two main ways. First, securing web APIs means that only authorised users can access them. Second, developing client-side security objects that control access to HTML UI elements.


This article is designed to help you develop secure Angular applications. It dives into Angular security best practices that can ensure your application remains secure from common web application vulnerabilities.


Cross-Site Scripting


Cross-site scripting (XSS) is a common web vulnerability where an attacker injects client-side scripts into the victim application. Such code can then be used to perform malicious activities such as stealing user data or escalating attacks by inducing malware. 


The attacker can also take advantage of the granted permissions to impersonate users.


Below are some effective ways of preventing XSS attacks in AngularJS.




A rule of thumb when it comes to programming is that you should never pass untrusted data to the compiler.


Angular, by default, is set to protect you from XSS attacks. This is because it applies input sanitization and output encoding for all data values pushed to the DOM. By treating all values as untrusted, it reduces the chances of introducing malicious data and other security vulnerabilities into your application.


When a value is pushed to the DOM in the form of a style, property, attribute, class binding, interpolation, or any other resource, Angular automatically sanitizes the value before rendering it safe. 


There are three main functions for sanitizing values:


  • sanitizeHTML function – It sanitizes HTML values by parsing them and validating their tokens
  • sanitizeStlye function – It uses regular expressions to sanitize untrusted styles and URL values
  • sanitizeURL function – It also uses regular expressions to sanitize untrusted URL values


Through these functions, the DOM Sanitizer cleans untrusted values to ensure only safe data is passed to the application. Here is a basic skeleton of the DOM Sanitizer class:


In the code snippet above, there are two distinct methods. One is the sanitize () method, which identifies both the context and the untrusted value. 


The second is the bypassSecurityTrustXXX () method, which gets untrusted values according to their usage and returns trusted 0bjects.


Implement Content Security Policies (CSP)


Content Security Policy is a web application standard that allows developers to establish trust policies, thereby providing an additional security layer. Angular’s compatibility with CSP helps detect and mitigate injection attacks such as cross-site scripting. 


You can learn more about CSP by visiting the MDN website or checking the Angular ngCSP documentation.


Strict Contextual Escaping


Strict Contextual Encoding is an escaping and sanitization technique that was introduced by Angular following the deprecation of the ng-bind-html-unsafe directive. SCE enables sanitization and escaping of values based on a specific context as opposed to the HTML element’s data. This is implemented using the angular $sce service.


Worth a mention is that abusing SCE is dangerous and can easily open up your application to XSS exploits. It is therefore wrong to mark untrusted values as safe through methods like $sce.trustAsHtml or $sce.trustAs(type, value).


Avoid Using Risky DOM APIs


The angular.element API provides an easy way to access and manipulate the DOM directly. However, it does not protect your application from potential injection vulnerabilities. Instead, you should use Angular templates and data binding when interacting with the DOM.


Below is a simple template and its corresponding angular controller



As you can see,  there’s a security risk in the controller. The element.after() appends data in $scope.content into the DOM without sanitizing or encoding it. 


If the values in $scope.content contain malicious elements, then Angular protection mechanisms are not applied, leaving the application vulnerable to injection attacks.


Server-Side XSS Protection


Mitigating server-side code injection is another way of defending Angular applications against XSS vulnerabilities. Although server-side code sanitizes malicious entities such as HTML scripts, it is not always aware of the AngularJS context on the client-side. 


Attackers can thereby provide maliciously crafted Angular templates leading to an injection attack.


To prevent server-side code injection, developers should:


  • Avoid mixing client and server-side templates. Instead, treat templates within a single application context.
  • Avoid generating templates using user input.
  • Avoid running input through $scope.$eval
  • Bind template data to ng-bind to ensure all input is properly handled by Angular’s sanitization and output encoding controls.


HTTP-level vulnerabilities


Two HTTP security issues can affect Angular applications on both the client and server-side. These are cross-site script inclusion and cross-site request forgery. Fortunately, Angular comes pre-configured with in-built helpers to mitigate these vulnerabilities at the client-side. However, to eliminate the threats completely, backend server cooperation is necessary.


This section will provide more details on how to deal with the two HTTP-related vulnerabilities.


Cross-site request forgery


Cross-site request forgery (XSRF or CSRF) is a form of attack where the adversary redirects the victim to a different web page, which in turn sends malicious requests to the server.  


Assume a user is logged into a mobile banking application and the user opens a link to a malicious The malicious can send a request to, perhaps a money-transfer request. 



The browser will automatically send this request, including the authentication cookies. If the mobile banking application server does not have XSRF protection, it will not differentiate between a forged request and a legitimate request.


To mitigate XSRF attacks, you must ensure that all user requests are coming from the real website. This requires explicit action at the client and server levels. Some prevention practices include:


  • Sending an auto-generated authentication token in the cookie.
  • Checking the origin header as sent by the user’s browser.
  • Hiding the authentication token such that only your application can read it and checking it upon form submission.


For information about dealing with CSRF attacks, check the OWASP CSRF Prevention Cheat Sheet


Cross-site script inclusion


Cross-site script inclusion (XSSI), sometimes referred to as JSON vulnerability, allows attackers to steal information by including vulnerable scripts in the victim’s application. In an XSSI attack, the attacker uses the <script> tag to include an API URL, which allows them to read application data. However, the attack only succeeds in instances that the JSON response is executable.


As such, one of the most effective ways of preventing XSSI attacks is adding a prefix that makes JSON responses non-executable. In Angular, the HttpClient library achieves this by polishing off the string “)]}’,\n” from all JSON responses.


Stay updated with the latest Angular releases


Like any other framework, it is important to use the latest Angular libraries. The Angular team is consistently updating its software libraries with bug fixes, security-centric patches, and feature enhancements. 


To check new releases, track the Angular change log, and make updates as soon as they are available. By doing this, you can fix and avoid security defects that were present in older releases.


Finally, avoid modifying Angular library files. If you customize or add hacks to Angular files, your changes might alter the existing functionalities and open up your application to some security issues. 


Additionally, relying on modified library files makes it impossible to upgrade to newer libraries. So, if you want to stay away from security vulnerabilities, use the latest Angular copy as it is.


Follow the above tips to keep your Angular applications secure. Happy coding!


Guy Bar-Gil

Guy Bar-Gil / About Author

Guy is a product manager at WhiteSource, where we enable software development teams to integrate open source fearlessly and without compromising agility. Before WhiteSource, Guy worked for the IDF's intelligence division, where he spent time as a combat operator and project manager. Outside of work, you can find Guy reading (everything from fiction to physics), playing and watching sports, traveling the world, and spending time with friends and family. LinkedIn