Hasty Treat - Client vs Server Data Validation

Monday. Monday. Monday.

Open wide dev fans. Get ready to stuff your face with JavaScript, CSS, node modules, barbecue tips, get workflows, breakdancing, soft skill, web development, the hastiest, the craziest, the tastiest TS, web development treats coming in hot. Here is Wes, Barracuda, Boss, and Scott, El Toro Loco, Tolinski.

Welcome to Syntax. On this Monday, hasty treat. We're gonna be talking all about client for server side validation.

And it's gonna be more than just, like, form validation because, obviously, form validation is a big one, but there's a lot of other things in terms of Checking and validating your data on the server before it does anything serious, and we're talking maybe Changing information or placing orders or whatever, all of those things we're going to get into in this episode. My name is Scott Talinski, and I'm a full stack developer From Denver, Colorado. And with me as always is the US boss. Hey, everybody.

Excited to tell you my story today. Yeah. Yeah. This was this episode is actually the the genesis of it. It was from a Twitter thread that Wes had done, and and I read it and was thinking, man, that would make a great lesson For some people on an episode. So this episode is sponsored by one of those sponsors that is just really a joy to use and one of these things that you're going to need to try out yourself, and I'm talking about Netlify. Now Netlify really took the hosting game to another level. When I first tried Netlify, I said, this is the product I've been waiting for for so very long. You can see why over a 1000000 developers and businesses use Netlify. Head over to netlify.comforward/syntax and check it out. It is free to get started. What are some of the coolest parts about Netlify? Well, for those of you who are just wanting to get a website up and live, if you just select your repo in Netlify and then maybe it's built with something like Gatsby or Next. Js, it's super easy to tell Netlify how to build that site. And when you build it, you get all these things like continuous integration and continuous deployment on pushing To specific branches for free. Not only that, but there's a ton of extra features involved here. If you need some of that server side Functionality like functions or contact forms or user accounts, all that stuff is baked into the platform.

So check it out at netlify.comforward/ Syntax, give it a try. Free to use. I host my stuff on Netlify, and I know you host quite a bit on Netlify as well, Wes. Right? Yeah. I host

My personal website as well as the uses .tech website on Netlify.

Big fan of it. Yeah. Me too. Cool. So let's get into it. This, again, all started with a Twitter thread. So, Wes, I thought it would be nice for you to maybe do a recap and talk about what happened in that thread Maybe exactly the story overall, what happened to you, and we can use that as a jumping off. Yeah. It's it's kind of a funny story. And let me preface it by saying this might have not have been the most morally sound thing to do. I got a lot of flack from people saying, like, you probably shouldn't have done that. And it made me feel a little bit bad, and I probably shouldn't have done this. But for the sake of you learning about server side validation, we're going to tell the story, and everything did end up fine. So What happened is my my dad texted me a screenshot of he uses this app called Flip App, and there was these, batteries on sale For our drills that were, like, super heavily discounted. Like, they for some reason, they were clearing out the 1 packs of them. So rather than them being a $180, they're on sale $30.

I thought, oh, that's amazing. And so he said, oh, okay. I'll send you a link. And then he sent me the link, and, All of a sudden, it was gone from the app, so they they must have run out. And I thought, oh, shoot. But he had a screenshot of it. So I Went to the website of this retailer and and thought, like, oh, I wonder if it was like a mispriced or if they are totally out. So I found the product on their website by downloading the site map because it was unlisted from the it was unlisted from the website, but it was Still in their sitemap.xml.

So I found that. I went to the URL of the product, and there it was. It was on clearance, so They just heavily discounted it so they could they could get them off the shelf. And I said, oh, that's too bad. I I I wish I coulda got that. And so I started poking around. I was like, oh, it uses React.

So I got into React, and I got into dev tools.

And I also, and I found the state of the component that is the buy it now thing. And There was a Boolean called is available online, which was set to false, and a object called inventory.

So I changed the inventory to, like, 5, and this is all client side. This is just in my browser. I didn't hack into any system, and they changed the is available Boolean to true. And then all of a sudden, the echo form showed up. And I was like, oh, great. I was like, I wonder if they still have, like, any in stock. Like, sometimes they they hold a couple back. So I added 1 to my cart, and I checked out, and it let me check out. Like, it it let me add it to my cart, and then I just refreshed the page, and it was still in my cart. So I went and checked out, and it allowed me to to select shipping options. So I select the shipping option. I put my credit card number in, and, I got the confirmation email. Thank you. We'll let you know when, Your order has been processed. 10 minutes later, your order's been processed. Thank you. I was like, alright. We'll let you know when it ships. So it's like, oh, maybe it actually did work. N. On the page, it says, we reserve the right to, like, cancel orders because these are clearance items. So I was like, oh, maybe I did get it. And then I ended up, getting a cancellation email, like, 20 minutes later because they're out of stock and whatnot.

So I tweeted it. I was like, oh, man. Like, I can't believe I was able to change the Boolean of is available to true on the client side, and then it let me Add it to cart and checkout and and everything. And there along the way, there was no immediate server side validation. They obviously had I had validation on there at the end when they went to try to ship it, and that wasn't in stock. But it still let me add it to cart, and there was no checks there. It was only client side, meaning The only thing stopping you from adding it to cart was whether or not the button that says buy it now was Display none or display block. Mhmm. Right? Yep. So that that was the thing at the end of the day. So I thought, like, that's really interesting. Like, it's they only did client side validation, so we're gonna do a Show on, like, what is the difference between client side validation, which is browser, and server side validation, which is when the checkout actually happens.

Yeah. So I think a good place to start would be on the client because that's the 1st step of the process. Right? Well, in some cases, it's the 1st step of the process. In other cases, it's not, but, we gotta start somewhere. So what is the role of client side validation overall? And I think for me, the message with client side validation is largely based around user experience rather than anything other than that. As in the client side validation messages, whether it's in a form or otherwise, are largely there just to Guide the user to say what they're doing right or wrong. Right? Whether or not it is submitting a contact form. Right? You submit a contact form. You put some HTML five validation on your forms, and one of those is maybe like a type of email. When somebody puts in something that's on email, The form will say, hey. This isn't an email, and that's largely for the user's benefit more than anything else. And to me, that's that is the big message. It's all for the user's benefit when you get into client side validation. Is that how you think about it? Yeah. You you should not Rely on validation

in the browser to control any of your application's logic. It's simply to Help the user input the correct data and make sure that they've they've done it correctly, instead of having to submit it to the server, wait for that to come back, and And then tell them then something went wrong, because we've all been there where you're on a website, you submit the form, and then it comes back. Half your fields are missing. You have to put your credit card in again. They don't save the credit card data, obviously, on the server, and that's really frustrating. So it's just sort of a nice to have little guidance, but it should never be a security or business logic thing. Yeah. Nice to have guidance is a perfect way to look at it because when you look at it as anything more than a nice to have guidance, Actually, this is a pretty good metaphor. It's sort of like my speaker stands where I have a my giant studio monitor and my speaker stand on there. It's really nice, But if I actually lean

on it at all, the whole thing's gonna fall over. So, like, you you shouldn't be able to do any more than just Ever so slightly lean on it. Right? If you put any weight on it whatsoever, the client side validation

should not be doing anything to hold anything up, Essentially, in terms of security wise. Totally. And we should be very clear because the reason why you shouldn't lean on these is because people can change it. If a field is required, Someone can inspect dev tools and take that required off. If a Boolean is marked show checkout button, someone can take that off as I did my regrettable story that I did. So, like, you need to make sure that people are not monkeying around with the data. And that's also true because if we think about lots of new interfaces, That we are building.

If you have, like, maybe a mobile app and then you've got a website and then maybe, like, you might even have Something else. You generally have 1 API, and that API should have all the validation baked in. And then the actual UI layer Could be implemented in many different ways. So having it at the server side level, both is good for security as well as just Being able to make sure you've got all of your bases covered, you don't have to necessarily reimplement every single type of validation on each client.

Yeah. Totally. And this also I mean, largely, they show the correct UI at any given point. For instance, like, we validate whether or not somebody is a Pro subscriber. Right? If somebody is if somebody's purchased access to the premium materials on level up tutorials, Right? That is largely a Boolean flag on level up tutorials.

So if you change that Boolean flag to say, oh, I'm a pro, CSF. Don't expect that all of that data is now going to be available to you because we not only validate the data as it's coming into the server, but we also validate the data as it's coming out, as in we're only sending you the data that you actually have access to. So even if you Change that UI validation on the front end of things. You're not gonna, all of a sudden, get access to a treasure trove of the stuff that you shouldn't have access to. Right?

Another good example I have is coupon codes both in Oh, yeah. My advanced React course and on my own website. The coupon codes And the actual price of the product is stored in the client so that when you add a coupon code, it will immediately update the visual price of it.

And I've had lots of people find that and change the price of the course to 1¢ and think they're super smart until they see their credit card bill and they get charged The full amount. Why? Because, obviously, I'm recalculating the price of the course on the server side where you're not able to monkey around with it. I have to send what product you want, Well, coupon you're using other any other information, and then I have to run the that recalculation again on the server where it's not Based on inputted data from the user other than what are they trying to buy and what coupon are they using.

Totally. So let's get into the role of Server side validation, and then we can even dive into a little bit more. I had a little bit, like, maybe what a, like, a store should be doing, Validating certain things. So let's get into the role of server side validation. And the role of server side validation in general is to prevent your application from doing anything it shouldn't be doing, whether that's updating records, creating records, deleting records, And you could think of that as something like even adding an order. Right? Adding an order is updating a record or adding a record. Right? So if that order is not CSF. Correct. If the price is not correct, then the server should be able to validate that information before it ever hits your database or it confirms a sale Or it does anything like that because that is what the role of the server is. Right? The server is going to be all of the security aspects of things. So In my mind, what we need to do is you need to validate all of the types that come in or all of the the types of the data When it first hits your server, make sure that the types are what you're expecting them to be. That way, you're not potentially looking at inserting any Code or or any weird things in your database. Right? So you validate the types of the information that's coming into your database, and then you also need to Validate the data specifically whether or not it is checking to make sure that the product that they're trying to buy actually exists, so the price that they're trying to buy, it actually exists at that price. Right. Yeah. Yeah. Absolutely.

Alright. So flipping over, we kinda talked about server side validation. But, generally, the way that works is before you Input your data into the database or before you do a lookup or before or anything, you make sure that the data that's coming in is correct. The email address is formatted in a proper way.

A lot of these validation things will also strip the plus off the email address. I saw somebody talking about this before where they're like, f. Let me use my plus email address where you like, west boss plus newsletters@gmail.com.

A lot of them will strip them off So you can store this is kind of an aside, but you can store the plus email address for things like mailing, which is good because then when you send them an email, it will it'll be filtered into the user's inbox How they want it, but then you can also strip it because all the time this happens to me is people sign up for a course with a plus email address, and then They forget what they used for the sign up, and then they're like, hey. It's not working. I reset my password, and I'm not getting the email. And Just normalizing that, but also still maintaining the the plus on it is is kinda key. Mhmm. What else does Server side validation do make sure that you're with well within ranges, phone numbers, things like that. One little thing that I hate is Formatting of phone numbers, you know, when you, like, put your phone number in, and it's like, please put dashes in it or please take the dashes out or Mhmm. Please put the parentheses plus 1 in front of it. Like, Can't you do that for me? Yes. Right. That's right.

So just I think you get the point. Right? It's just making sure the data is correct before you go ahead. And if it's Not you throw an error, and then ideally, what will happen is your client side code will also get the response from that post request and say, alright. It didn't work. You'll throw a toast message up or you'll highlight the fields that were incorrect. And, in some cases, I just prefer to do that. Obviously, you can have some very light validation on the client side, but if you have to, like, reimplement the same validation twice, it gets a little bit hairy, I think. What about you?

Well, it kinda depends on how you will have it all set up. But, yeah, I I agree. And the the nice thing about using GraphQL Is that the inputs and outputs from the server to the client are all typed correctly. So that way, it, like, makes one Step of this very easy. You don't have to worry about checking the type validation between the data that's coming in across your API because the inputs are typed and everything knows what it has to be coming from the the client to the server. So I I thought I would do a neat little rundown of, like, maybe what a process for this might actually look like. So, like, for instance, right, we we have an order come in. So that data first comes in. And, again, I think the first thing that Should happen is that you should validate that the types are correct. You know, the order number is a string. The user ID isn't string, or an ID, or whatever. But either way, all of these types should be validated as the information comes in. I used to use a package in Meteor called the validated methods, which was, like, really Similar to sort of how TypeScript does it where you just basically tell the object what the type should be. And if that information comes in incorrectly, then it it throws.

But this is, again, this is very easy with with GraphQL because that's just gonna happen automatically. Everything's all all typed.

Next thing is the you wanna check the current Stock and price information, but what you don't wanna do is trust any of the information that's coming from the client. You don't wanna trust it. Like Wes said you could change that that price. And if that price comes in, the last thing you wanna do is go off and process that order with the price that the people sent you from the client. So what I do is I check the ID. So I I look at the cart, the shopping cart that's been sent to me, and it's like the IDs of things that have been purchased.

Then I check the current stock, which I don't have any of because it's all digital projects, but I would check the stock and check the price information whether or not it's on sale or what the current price is. And then I would get all that information back, and I would check the totals to see if the total coming in from the client is exactly what I have coming in from the server side. So, like, if the server side says the total is $150 and the client says it's $150, then we're gravy. Now the reason why I do this is because The the the number that's coming in from the client is what the user's expecting to see. Right? That's what they're expecting to be charged.

So it'd be a good idea to make sure that they're being charged what they're expecting to be charged, but I do use the amount from the server. That way, we have, like, a little bit of a throw to say, hey.

You know, maybe something went wrong in the process or these numbers aren't aren't what you might be expecting.

So at that point, you would then process the order. If the price is correct, the amounts of the totals are correct, all that information's correct, you can then go ahead process that order and send it back the correct information.

And so this is also another fun point. What if you don't want somebody messing with your react state or your react state overall? Like, what if you have a react state and you're like, you know what? Like, I just don't want anybody messing around with that client side information anyways. And, you know, sure enough, people can do it with JavaScript, whatever. But What if I don't wanna give people access to the React dev tools? Well, there is a package for that. I'll have the link in the show notes. It's called disable React To dev tools, and it's a one liner where you basically check the process. D n v variable, where you say, hey. If we're in production right now, Then run this function, disable React DevTools.

Bingo, bango. React DevTools won't work in the production of your application.

And this is something we do on level up tutorials ourselves, Not because we don't want people learning from our code, but, like, I just I've always been in the the mindset where you're trying to remove or hide as much of the development Cool as as you can in production. For instance, when we had WordPress sites or Drupal sites, we would change the default login URL Every single time because there's bots out there that are gonna be looking for some things. Right? And they might be looking for wp_login or whatever it was or hyphen login.

And so if you change those things, it's just removing 1 step of the equation for for maybe some automated tool or somebody who knows what they're doing, who's trying to get in there and and really be malicious. So another step in client side validation might just be removing some of those Opportunities for people to, to manipulate client side stuff easily. And I'm talking easily because client side stuff can be manipulated no matter what. It's it's just a matter of making it a little bit harder.

It's true. It's it's the same thing with, like, locks on on something. Like, A a lock on your gym locker. A lock on your your shed is not going to keep somebody out who really wants to, But it's going to stop a lot of just sort of, like, half hearted, random passerbys.

Like, I've I've had Stuff stolen from my garage, like, 4 times since we've lived here. And every single time, it's because I forgot to lock the freaking garage. You know? Like, the guys, they they're not kicking in the door Or pick like, I love watching lockpicking lawyer on YouTube. Lockpicking lawyer. Pick anything. Any lock is undefeatable. But In most cases, your, like, $8 lock is gonna keep out a majority of of the people, and it's just another step. It's obviously not bulletproof. Like, Somebody will probably come out with a Chrome extension called disable, disable, or react dev tools. And,

You know, like, that will flip flop back and forth. And if somebody really wants to get into it, they certainly can. But if I if, like, the website that I tried to buy this battery off of Had that, I probably would've given up and moved along. Right? Mhmm. I like to think about it as a a lock on our fence door. You could just jump over the fence if you wanted to, but that's a lot of work, and somebody might not wanna jump over the fence. They they but Doug, they might try that door. And if that door opens, they might come in. If not, then, Well, I don't really feel like jumping over this fence, so this is client side versus server side validation.

There's a lot here in general, but, again, don't trust anything coming from the client. There's a lot of reasons why. Just don't do it. Again, it's not secure. Especially if you're dealing with ecommerce or anything serious, you don't wanna give those users an opportunity To be able to, access things they're not supposed to access, get information they're not supposed to get. But more importantly, you gotta have a good client experience.

Well, maybe not maybe not more importantly. I would say secondary. You wanna have a good client client experience. Primarily is is security. Secondary, good customer experience, And that's that's where we're at. So thank you for tuning in in the next episode. We have a potluck for you. A lot of great questions in this one. So tune in on Wednesday for that potluck. CSF. Peace.

Peace.

Head on over to syntax.fm for a full archive of all of shows. And don't forget to subscribe in your podcast player or drop a review if you like this show.