Web Fortified: Best Practices for Web App Security

Hello, everyone. I'm so glad to be here at JS Nation this year and talk about one topic, which is really close to my heart. It's web security and how to stay safe in the world of dangerous enemies, attackers, you name it, because there are lots of dangers out there in the web.

And yeah, I want to show you how to keep your app as a fortress. But before that, real quick, my name is Ramona, Ramona Schwering. I'm working as a developer advocate at Auth0. And besides that, I'm a Google Developer Expert in Web Technologies and a Cypress Ambassador. So you might already have met me before talking about testing, but there are more and other really important topics to talk about, and it's security for this time.

Okay, so this talk is called Fortify or App Fortified. Try to see your app as a fortress. And if you think about fortresses, what do they do normally? Well, even if it's like a building you see in environment, if you travel or in movies, they protect something precious. And yeah, movies are actually the place where I saw fortresses a lot. And this little screen here has been taken from a movie I really enjoy. It's called Lord of the Rings. You might have heard about it. It's about a journey of a hobbit who needs to destroy a certain ring. And it's a trilogy. So there are three films, and especially the second one, the second part, I really enjoyed a lot, no matter if it was a book or the movie, like the one called Two Towers. And there's a fortress called Helms Deep in it. And it is meant as a refuge. So it's meant to protect all of Ulthuan, which are the people of Rohan, so like a region or country in the furthest meaning, I think. They should be protected from the assault of the Zaruman forces. And they had a disclaimer that it was never conquered. Well, never conquered, 100% security. I guess we heard it before at some point, right? Well, back to the fortress. You can guess, it didn't hold true. At least a part of the fortress didn't hold. And of course, as it's in movies, it's almost a cliche. It's again the Kilmaryr the Sear, which was a weak point. Hello, Devstar? It was the same as that was too.

So they have a cover being a weak point. And if you regard the books, they didn't even need it, as there's a gutter to take. And this led them to basically have the big first wall being blown off. And they almost have been overwhelmed. So yeah, there's no fortress which is secure all the time.

Why do I tell you that? So your application's protection can be regarded as a fortress, where you want to protect everything what's inside against outside threats. May it be data, may it be the features which you would like to have paid users or anything precious. And there's lots of precious things inside of a web application, right? So yeah, we should regard our application as a fortress.

And no matter if we are at Lord of the Rings, either in movie or media, or in the real world, the world is changing a lot. More vulnerabilities are coming up. So we should always be doubtful. Like Theodin is. That if we say a fortress or an application has never been fallen or attacked or hacked, we should be doubtful and really, really careful. Even if it was a late lesson for Theodin. We should never feel too safe.

So if we think about how to keep our web application secure, the first thing we need to think about are what are the dangers we need to keep our app safe, right? What are the most dangerous risks in web? Well, fortunately, there's a project which helps us a lot. It's the Open Worldwide Application Security Project or OWASP in short. And their goal is to raise security in web. And at a certain rhythm, they publish a top 10 ranking of the most important security risks. And I think the last ranking was in 2021. But please correct me if I'm wrong there.

And in it, we will take a look at the top three, because they are most significant and most important to take a look at, especially as we want to take a look at like the low-hanging fruit or like some small but easy to apply best practices to keep your application secure. So let's have a little spoiler alert. One of those three points is the most important for us in front of it, but the others are important too. So the rank one, that's something I want to cover because it's the first place in the ranking. It is important and there's something we as front-end developers can do.

It's the one of broken access control. This point is dealing with security risk in authorization. And as authentication is the first step to authorization because you need to know who you are, like who your users are inside of your application to know what can be allowed for it or what permission can be given to it. And yeah, as there are just a few front-end points to take a look at in an easy way. It's not the complete focus of this talk, but let me mention the first easy improvement. It's displaying generic error messages for authentication. Imagine you have a login form. Someone enters invalid credentials and you say like, oh, your password is wrong. This is not that idea because if the attacker sees this error message, he knows that the password is the thing you need to brute force. Like you just need to try out some other passwords because you know it's a password. So let's think of a generic error message like either username or password is wrong. So the attacker doesn't know what exactly is wrong inside of this login form, which helps us to be a little more secure. And as I said, being DDoS, we should think about a rate limit. So an attacker could just not like spam your application with all possible passwords, right? Having a little timer or like a rate limit where you like lock your application will help you a lot keeping your user secure. If you don't want to take a look at this point completely by yourself, you can think about using third-party libraries like Auth0, for example. Or of course, you could build it yourself if you are brave enough. There are examples to introduce, for example, JWT tokens for token-based authentication inside of applications, but there are plenty more. In front-end context, though, there's one point of the three, like being broken access control, cryptographic values, and injection, which is especially important for us front-end devs. So I guess you already saw it.

I want to talk about injection. Injection is actually the risk of an attacker supplying untrusted input to a program, which means in detail that the input may be delivered by an input field or other angles gets processed by an interpreter as a part of a command or a query. And this leads for this malicious input to be executed like your own program code. So it also is the execution of that problem basically. And those attacks include cross-app scripting or XSS2, could be SQL injections where you have the angle of a query or more.

And those injections could happen if data, which is supplied by the user, as example, an input field, is not validated, filtered, or sanitized, or you have dynamic queries or non-parameterized calls without context that we're escaping. So they are used directly inside of your interpreter. So it's pretty obvious why this is an important attack angle by a client or a front-end parts of your application.

So how can we prevent them? So most fundamental, and I really need to stress that, never ever use non-trusted content as your component template. If you're using, for example, Vue.js, which I will use as an example throughout the talk, but I try to be as agnostic as possible. But if you're using React or Angular, Swift, or any other framework, look that up. It wouldn't be that different, because if you use non-trusted content or content you can't control as your component template, it will be equivalent to allowing arbitrary or JavaScript execution inside of your application. I know that in Vue.js context especially, a template will be compiled into JavaScript. And all expression inside of those templates will be executed as a part of the rendering process. So please don't do this. Just don't. Only add trusted content, which is controlled and trusted by you.

And please don't expect your framework to do heavy lifting, because there are some features your framework, maybe Vue, React, Angular, will help you be protected. But it's impractical, especially on a performance standpoint, for your framework to do all the lifting for you. Nevertheless, your framework might be a first line of defense you might need to take a look at. As said, I will use Vue.js as an example, because I'm a Vue developer, but you can easily look it up for React or Angular, what they are, provide you as features for security. So, which measures can a framework already provide by themselves? At the example of Vue right now. Let's take a look. So, injection is easily prevented by using proper escaping of content, for example. So, escaping script strings, special characters. So, script tags, like I'm having here, like down below this bottom code snippet, cannot be executed in any way. And if you use a user-provided string in Vue, which contains the script mentioned in this regard, it will be escaped to this. So, the script is not there anymore, it's escaped. And this will prevent script injection. In the case of Vue, the escaping is done using native APIs, like TextContext. And a similar thing is being done with attribute binding in Vue. So, bottom line is, if your framework is providing you functionality for escaping user-supplied input data, please use it. As said, your framework might do already a lot of providing security features, but it cannot be the only thing you rely upon, as it's just too much to ask. So, it will always be the case that the most important protection is you yourself. So, I'm aiming at how you build your application or how you apply standards and some best practices. So, let's take a look at some practices and things to consider, which will help you raise the security inside of your application kind of fast.

Let's consider adding links by binding the href attribute. So, I'm actually talking about user-provided URLs, which could contain wrong Vue directions or JavaScript embed, like here. Cases I could think of in this regard might be connected to phishing, by constructing and entering a URL inside of your application leading to a malicious website, or a reflected course subscription.

So, there's a URL being displayed in the web application. But an attacker will add some JavaScript to the URL. Again, sanitizing will help you a lot in skipping. So, you could think about using libraries such as sanitizeURL to help you. I guess I will put it into a tweet, so you can find it even more, because I see I didn't add a QR code. But do not forget your backend, too, as your backend should always sanitize user-provided URLs before even being saved to a database. And last thing, but still important, be aware that URLs can always navigate to unsafe destinations, even if they are safe destinations at the start. So, it's still the point where you give up control.

Well, next type of injection, style injection, some type which surprised me initially, because I was like, huh, styling with CSS, right? How can this be an attack angle? But there's a point. There's a tech called UI redress attack. Imagine, you have a hidden UI in control. So, an attacker will style. Okay, let's start like an example. You have a login form with like a login button to submit your credentials, and the attacker will style this login button as another transparent box covering this login button. And then, styling a link onto it. So, you will not submit your login credentials to the page you expect, but leading to a fake login page by just having a transparent box above or covering your login button. Redressing, actually. So, with this user-provided styles here, directly supplied, malicious users could still provide CSS to click check. How can we prevent that? Well, we should allow user to only adjust styling in a sandbox or safe way, like having a sandbox iframe, or only allowing full control of CSS inside safe way. It's like in this regard, the user can only set a certain color or only a certain background, all those changes which are not that dangerous, right? So, yeah, there are lots of ways to keep them safe by just limiting the scope where a user can have provided styles.

Of course, there's an attack angle in JavaScript themselves too, which is called JavaScript injections. And there are just some things you shouldn't do in Vue at least, but also when it comes to other frameworks. Because just from a clean code standpoint or like a maintainability standpoint, templates and render functions shouldn't have any side effects because it makes debugging it a nightmare. So, you should avoid having attributes accepting Strings.js. So, it's unclick, unfocus, events, attributes. And the scripts, of course, itself shouldn't be used in any complement. So, those ones should be avoided.

Well, another point, which was mentioned, I guess, at the seventh rank. So, I didn't mark it in the oldest ranking, but it's a best practice to always take in mind. If you have a project who looks like this, like the small test project I set up. So, normally, it's not in production. But no matter if your project is already in production or just in development mode, it should never, ever look like this. So, outdated like having, yeah, so many vulnerabilities in it, even two critical ones. Please, ever try to keep your NPM packages or packages of whatever package manager you use and your framework updated on the latest state. And there are a couple of things how you can ensure it without putting that much work into it. Like using Dependabot if you host your project on GitHub or using NPM audit or similar commands. Taking a look at CWA databases where publicly disclosed vulnerabilities will be mentioned. So, please keep your projects up to date and don't wait for too long when it comes to applying security patches.

Okay. When it comes to keeping your web applications secure, when it comes to having your application as a fortress, when it comes to my talk, there are a few things I want you to remember. Actually, four things to remember. First, may it be Vue, may it be React, may it be Angular. Your framework is the first line of defense and you are the second more important one, but you are the second one which makes the most difference. Please, never, ever use non-trusted templates or templates. You cannot control templates which are not your own. Templates you don't trust. You can apply many small best practices like sanitizing, like escaping, like limiting the scope of the things a user can supply. Lots of those things. And last but not least, mind your dependencies. Keep your projects up to date.

Here I put some QR codes for more best practices which helped me a lot, which I really used the framework agnostic like the HTML5 best practices of a complete page of the OWASP. It always makes sense to take a look here. And I will search for more resources myself and will publish them in Twitter, so I don't eat up too much of your time because, yeah, there are so many things you can do. Well, what's left to say then? Thank you for listening to me, for being here, for being interested in security topics, and that we all try to make the web a more safer place for us, for us developers, and for the users. If you got any questions, just, yeah, just ask. Just find me on all known platforms like Twitter, Mastodon, LinkedIn, and, yeah, see you. See you soon. Goodbye.