Security Considerations

In any web application development, utmost importance should be given to the security aspects. When AngularJS is being used as the framework, there are specific security considerations and techniques that should be kept in mind by developers. In this tutorial, we will take a deep dive into some of these best practices.

AngularJS, like any web application, may face threats from both external and internal sources. While external threats refer to attacks like cross-site scripting (XSS) and man-in-the-middle attacks, internal threats are risks that arise due to the application's own vulnerabilities, like poor structure or insecure code.

Let's take a closer look at the most common security risks and how to mitigate them in AngularJS.

Cross-Site Scripting (XSS)

Cross-Site Scripting (XSS) is a code injection attack where the attacker inserts malicious scripts to the web page viewed by other users. These scripts can access any cookies, session tokens, or other sensitive information retained by the browser on that site.

AngularJS provides a built-in defence mechanism against XSS attacks. By default, AngularJS treats all values as untrusted.

Mitigating an XSS attack

The best way to prevent an XSS attack is never to insert arbitrary HTML codes to a website. However, if there's a need to do this, AngularJS' Strict Contextual Escaping (SCE) service can be used.

Take for instance, a movie review application where users input their reviews (that might sometimes contain HTML elements) about the latest movie they've watched. For such requirements, using AngularJS's $sce service can be a good option.

var movieApp = angular.module('movieApp', []);

movieApp.controller('ReviewController', function($scope, $sce) {
  $scope.userMovieReview = '';
  $scope.loadMovieReview = function() {
      $scope.userMovieReview = $sce.trustAsHtml($scope.userMovieReview);
  };
});

In this scenario, $sce.trustAsHtml is used to manually mark a string as trusted HTML. This is especially needed when using AngularJS directives like ng-bind-html to embed user-supplied content.

Note that making your website dynamic by directly embedding user-controlled values is risky, and ideally, it should be avoided or strictly limited.

Cross-Site Request Forgery (XSRF)

XSRF or CSRF (Cross-Site Request Forgery) is an attack that tricks the victim into submitting a malicious request. It infiltrates the victim’s browser and forces it to make an HTTP request to an innocuous-looking site. The site, however, is controlled by the attacker, who can then steal session cookies and other sensitive data.

Mitigating a CSRF attack

AngularJS provides a mechanism where it adds an anti-CSRF token to a HTTP request, which can be validated on the server side. This technique is called XSRF-TOKEN. This will ensure that all the requests are made from a trusted source.

movieApp.config(['$httpProvider', function($httpProvider) {
  $httpProvider.defaults.xsrfHeaderName = 'X-XSRF-TOKEN';
  $httpProvider.defaults.xsrfCookieName = 'XSRF-TOKEN';
}]);

In this example, AngularJS reads the token from cookie 'XSRF-TOKEN' and adds it to every HTTP request as a header 'X-XSRF-TOKEN'. Server side frameworks that handle CSRF also expect this header in all the requests.

Insecure Direct Object References (IDOR)

Insecure Direct Object References occur when a developer exposes a reference to an internal implementation object, like a file, directory, or database key without any proper authorization checks being made.

For example, consider a movie ticket booking system where a user’s ticket details are directly referenced by the ticketID in the URL.

http://mybookings.com/tickets/98765

An attacker could change the ticketID value in the URL manually and might get unauthorized access to the ticket details of other users.

Mitigating IDOR

Instead of relying on direct references, use indirect object references. In the above example, instead of using the direct ticketID, use session-based reference maps. Instead of exposing the ticket ID directly, a temporary reference ID can be created and stored in the user’s session.

Although AngularJS does not provide a built-in feature to prevent IDOR attacks, it is a good practice to use server-side sessions to map temporary indirect references with the actual business objects.

Conclusion

In conclusion, always approach your application design with a 'security-first' mindset. AngularJS provides some of the fundamentals for preventing common web attacks, but it can't do everything. It is essential for developers to educate themselves on potential vulnerabilities and keep up to date with the latest security best practices. As with all aspects of programming, continual learning and improvement in the area of security is key. After all, the security of your web application is as strong as its weakest link.