Interview with Ryan Chenkie, Part 2: Security in Angular
Agiledrop is highlighting active members of different open-source communities through interviews focusing on their projects and initiatives, as well as trends and innovations in the digital sphere.
This time we'd like to introduce Ryan Chenkie, JavaScript & TypeScript developer and digital security expert. As a GDE for Angular, Ryan is also an active speaker and teacher in the community.
In part one of our interview, Ryan shared his insights on the importance of security in the digital world and his thoughts on the state of digital security going forward. Part two is more Angular-focused: we discuss best practices for securing Angular applications and the state of the framework's security, then finish with some other things that Ryan is excited about in the JavaScript world.
1. What are some best practices for application security, especially for Angular apps?
When you’re building an Angular application - let’s say it’s an app that users need to log in to in order to make use of - there’s a good chance, especially in 2020, that you’re probably using something like JSON web tokens as your authentication mechanism.
There are a number of older instructions, blog posts and tutorials, that will tell you to put your JSON web tokens into local storage as a place to keep them, and there are a lot of people still doing that.
I would highly recommend trying to refactor that as soon as possible. This has historically been accepted as a good place to keep your JSON web tokens, but it really isn’t, and that’s because local storage is scriptable.
So, if there’s ever a scenario where someone gets some malicious scripts on your page, it’s very easy for those scripts to look into the local storage of any of the users who get that script on the page, and to do something like sending those tokens to a remote location where they can be collected.
And that’s bad, because a token, whether it be a JSON web token or another kind of token that is an artifact of an authentication process, is kind of used in place of the username and password. That’s its purpose - instead of you as the user always sending your username and password, now you’re sending this token.
JSON web tokens themselves have some features that make them a compelling mechanism to do authentication, but in reality, the people who are stealing these JSON web tokens, they are stealing usernames and passwords, because they’re stealing a set of keys that can be used at an API, for example.
Now, that key is going to expire hopefully at some point; but maybe it doesn’t, maybe you’ve got a core setup where you’re not properly setting an expiry time for your JSON web tokens, which needs to be refactored as well.
All that to say - local storage is a very easy place to steal those from. Instead, I recommend refactoring that to an HTTP-only cookie, which removes this susceptibility to process scripting.
It does open other possibilities, like through CSRF (cross-site request forgery), but if it’s in an HTTP-only cookie, you’ve got some security mechanisms to help prevent that, so I would say storing your token in a cookie is quite a lot better than storing it in local storage.
Another thing you might think about is whether you need to use JSON web tokens at all; perhaps you can just use tried and true cookies and sessions if that is a possibility for you.
JSON web tokens are interesting and useful, especially when we’re communicating with data APIs, but it’s still very possible to do cookie and session authentication as it has historically been done in round-trip applications. So, make sure you implement your authentication mechanism correctly.
Another big one that I recommend is, don’t ship code to the users’ browsers that they don’t need. We’ve got a lot of good tools with Angular to be able to easily split out our application into different chunks, so we can do lazy loading of the route boundary quite easily, it’s just a simple matter of setting your route config.
And if you’ve got an application that maybe serves your users but also serves your admin staff, there’s no need to send all the code that powers the admin side to the users’ browser, which is going to be helpful because they’ll get a smaller bundle size. But, also, they will then not be able to access the front-end code that goes into powering that admin feature.
If you’ve got your application set up properly, you’re not going to include too much code that users would be able to use in any malicious way in your admin area. You’re not going to have, like, secret information in there, but there might be things in there that the user can browse through.
Because, remember, anytime you ship code to the browser, the user has all access to that source code. Even if it’s minified, if you’ve got a savvy user, they can use some kind of tool to expand that code and be able to step through and look at what you’re doing.
So, if you’ve got anything that could be a privacy concern, you really want to keep that out of users’ hands if at all possible. If you’ve got regular users, and you’ve got admin users, the regular users don’t need to see your admin side.
So, yeah, taking care of your authentication mechanism and doing smart bundles by lazy loading in your application, those are the two key things.
2. Do you think there are any areas in which Angular could still use some security improvements?
I’m impressed with what the Angular team does to help with security where they can. Much more so than other frameworks and libraries, Angular does a good job of putting these mechanisms in place.
So, if you’re using cookie and session authentication, they’ve got a mechanism for you to help with CSRF, like how to attach an anti-CSRF token; they help quite a bit.
There’s nothing that I see from a front-end side that I would say Angular really falls short in. They really take care to escape content that is rendered so that you’re not going to be running scripts that might have been injected by another user.
I guess if there’s one improvement I would say that they should give more thorough guidance on security. They do a good job of that in the docs, but like a more thorough rundown, such as how you would set up an Angular application that has authentication built in.
Cause that’s something most of us need - unless you’re building a trivial application, you need a good authentication setup. But it’s often up to the user to implement that, and rightly so, because it’s different depending on what backend you’re using and what your situation is.
So, perhaps more guidance that way, because what you’ll see in the docs is just an example of attaching a token, and there’s not really a token attached, just some pseudo code to show you how to do it. Especially for newer developers, more guidance around authentication in the first place would be good.
3. Has there ever been a major security issue uncovered in Angular core or in an Angular application that you recall? How was it resolved?
I don’t remember a specific app, but there was something called the expression sandbox in AngularJS. It got removed in Angular 1.6. It had something to do with user-generated content not being able to generate templates, something like that.
I’m not super familiar with the issue. I remember this being something that got raised, and obviously it was an issue because they removed the feature.
In terms of the latest Angular, I don’t recall anything of a security hole that was a big deal and had to get patched and everything. I think they did a really good job thinking through those things early.
4. Is there something that you’re particularly excited about this year in Angular and/or JavaScript? Either security-related or something more general.
Yeah - the new web authentication spec I mentioned last time, I’m really excited about that emerging spec, that’s going to be really cool to see.
I think from a user perspective, the convenience of it will be great, but also just from a security perspective it’s going to be great to be able to sit back and just rest assured that you’re not relying on usernames and passwords, which is an inherently weak form of authentication.
Changing gears a bit, I guess - I’m excited about React, I’m doing a lot of React work these days. I still love Angular, I still work a lot in it, but I have been focusing more and more on React.
I’m excited for where the library is at now too, especially getting away from the whole historical class implementation of React and rather moving into purely functional, using hooks and that sort of thing, so I’m liking that.
Some of these newer libraries are gaining popularity, I really still have to try them out. Like Svelte, for example - I haven’t really given much attention there but I’m interested in doing so, I’m excited about the possibilities with Svelte.
As for Angular as a whole, I am not too well versed in the differences that Ivy is going to make with Angular. I haven’t really taken it through its paces yet, but I’m excited for the fact that you will hopefully get all these benefits of Ivy that are being touted, you know, smaller bundle sizes, faster compilation, all this stuff.
I’ve heard mixed feelings about it, so I’m a little bit tentative, but I’m excited to see where it takes us, especially into the future versions of the Angular framework.
In case you missed part one of our interview, check out that post as well for some great insights on web security. If you'd like to learn more about Ryan or reach out to him, you can do so via Twitter.
