Now the security plus really likes talking about secure coding techniques. Basically, if we're writing applications, what are some of the security issues that we need to keep in mind as we're actually generating that code. So there's a number of these that are listed. And you know what, I'm just going to go right down the list has actually printed within the objectives for the security Plus, there's no particular order to them. So let's just get them all. However, before we start talking about these, I do want to make sure we're clear on one very important concept.
And that is the idea of compiled versus runtime code. For years, what we would do is you would write code, and you would write it in whatever programming language you chose, you would then run that code through some type of compiler, and then you would generate executable code. And anybody who's seen a piece of code with XC on the end or.com, if you go that far back, understands that these are programs that are run on your system that run through your RAM. Most applications that we run on the internet today are runtime applications. So what we'll have is like something built into our web browsers that can read, basically, highly refined code. In this case, it's not compiled, though it's not executable, it is interpreted by whatever client you have running.
So if we have a web app in particular You've got some choices here. First of all, you want the application to recognize errors, and put up a nice screen that you know, it says like oops, or sorry, or something like that, so that it doesn't do something evil. Now, here's an example of a bad error handling. Now, I bet a lot of you have seen errors, something like this, what you're looking at here is that the actual application doesn't know what to do with this error. And it has, if we're lucky, it's locked up. If we're unlucky, it could do evil things, like allow us to have root access or actually get into the system behind it itself.
So proper error handling is absolutely critical. Next is going to be proper input validation. Every application there is has some kind of input some kind of dialog box. So let's say for example, I've got an application that wants to actually have you enter a I don't know an email address like we see here. So as we're entering this email email address, we want the application to validate that it's a good email address. And you've probably seen this where if you don't type in something that looks like an email address with an add sign or something like that, the application kicks back and says, try again.
You could go even further than that, you could have somebody enter an email address, and then you can even have it then query that domain like total sem.com, and verify it's a legitimate domain. So that's really up to you in terms of what you want to do with input validation. Next is normalization. databases can be big onerous items. And one of the things we want to avoid is replication of data. When we normalize a database, we use tools like for example indexing, to take what could be just one database and turn it into two or more as needed to allow us to have zero or little replication of data and more efficiency within the database itself.
Next are stored procedures. Now, if you're going to query a database, you should be doing things like for example, proper input validation. Now, if we just leave it to the individual pieces to handle all this, we could run into trouble. So what we often do is we insert a stored procedure between those which are querying and the database itself. So what will happen is that the individual items will then query the stored procedure. And then the stored procedure will do input validation, whatever needs to be done, and then he'll send that to the database, stored procedures, protect databases.
Next is going to be encryption. Now, we got to be careful with encryption because we're going to talk about encryption again in a minute. But what I'm talking about right here is really what we're calling code signing. Your code itself is precious. We don't want people to be messing with the code. If we have updates, we want to be able to create Roll those updates.
So that basically means from a coding standpoint, you want to break down as many functions as possible into individual pieces. So the different parts of your code can continue to call it over and over again, as opposed to writing the same thing, two, or three, or four or 600 times with the risk of error. On the same token, dead code is simply code that we're no longer using. A lot of programmers are tempted to keep dead code in their applications, the motivation being they might need it or something like that. A good rule is get rid of dead code, cut it out. The danger to dead code is that sometimes bad guys can take advantage of little inconsistencies in your code to do naughty things.
So go ahead and just take that dead code out of your systems. The next issue is going to be server side versus client side execution and or validation. To make this more clear, let's set up a situation where we have a server and a client. Now in this particular situation, the server is serving up some web application. And the client has a web browser up actually accessing that web application. And let's say one of the things that this web application does is it has a dialog box where you type in your first name, last name, email, address, whatever.
And we then process that in some way. So if we do this on the client side, what we're doing is not only do we fill out the form on the client side, but we'd also perform for example, input validation, and then generate the query and just send the query over to the database on a server side. All we're doing in this situation is we fill out the form and then we send all the data good or bad over to the server, and then the server performs input validation and generates the query. There are good and bad aspects to both of these. And it really depends on what you're trying to do. Keep in mind that if you do stuff client side, you're putting a lot of onus and a lot of security on the individual clients, and you tend to be sending a lot of code to the clients.
On the server side, you tend to put a lot of work on the server. Things like encryption, for example, really come into play here. Depending on if you're just sending a little bit of data to the client, maybe encryption is not a big concern. Whereas if you're taking important chunks of a database, and sending it down to individual clients, then corruption can be a really, really big deal. Next is memory management. The bottom line is that all of these apps use memory.
Now I'm not so worried about on the server side, although that can be an issue. But this really does become an issue on the client side. It is trivially easy for us to make big, ugly applications that eat memory. So not only do we make programs that eat memory, but we can actually inadvertently put in memory leaks. Anybody who remembers Firefox five or six years ago, maybe a little more than that, it was a bit notorious for eating up all the ram in your system. Whenever you ran some types of web apps, Firefox is great.
The downside to third party libraries is that they can Be big security issues. A lot of times bad guys will not be able to attack your app itself. But they'll find a weakness because a lot of these apps are used by hundreds of thousands of people. So if a bad guy can find a weakness in one of these third party libraries, well, they can take advantage of lots of people not because you've written a bad app, but because a third party library that you lead on has a weakness. The bottom line here is a lot of staying on top of things and lots of patching, and making sure you're aware of weaknesses and vulnerabilities as they appear. The last one is data exposure.
And that's where I really want to talk about encryption. If you have data that is a part of your app, some of that data has risk of exposure. And our job as developers is to reduce if not eliminate any risk of that data exposure, especially if it's personally identifiable info or personal health information. We almost always today go through aggressive encryptions. Anytime, if for example, we bring some data down to a client, I promise you on a good app, all that information is always encrypted. It's really not even.
There's not even an excuse to not do that anymore. So make sure if you have data exposure, you're going to be using lots and lots of encryption. We covered a lot of different secure coding techniques in this episode. Now, look, security plus is not trying to turn you into a code head, but it is expecting you to understand some of the basic concepts of all of these very important secure coding techniques.