An important thing when we're designing our application is to ensure that we have what are called Secure Defaults. So what we mean by this is we want the default behavior of the application to be secure. Now why would we want this? Well there's a number of reasons. One, for example, is if other developers are going to be interacting with our code, they may not understand the best way to interact with our code. Or another way to look at it is I, as a developer, tend to be lazy, so I like to get things done in the easiest, simplest way. And often the simplest way to interact with a code is the default way of interacting with the code. So, when we're building mechanisms that other developers or ourselves are going to interact with, we want the default behavior, the easiest mechanism of use of that code to be the secure way of operating. Now, one we want to do this for other developers and ourselves. We also want to to do this because we may not realize all the types of inputs that our application is going to receive and we may not be able to think through fully. And it's almost definite that we can't think through fully, what our application is going to see at runtime. So, if we have a default behavior for how we handle data, or how we store data, or how we send the data, we want the default behavior to be secure. So, we're going to deal with other devs. We're going to deal with unexpected input. So we're going to deal with unexpected input and we want to make sure that when we see something that we haven't seen before, and until we know otherwise, that we treat it with great sensitivity. And we're also going to have users who may not initially, when they're using our app or may never be fully trained on how to use it properly. So we may have people who are users that are inexperienced, and they may not use our application correctly. There may be cases where our application is running in an environment that we haven't thought about and we want overall the default behavior to be secure. Now, this is really important when we create apps that are sustainable and popular. So, there have been all kinds of interesting vulnerabilities that have come out where the default behavior of an application is insecure. So, for example, an application may have a default password or username, or a default port that it binds to, that isn't secured. And in order to install the app, and harden it and secure it properly, you have to go and change some configuration files to alter those settings. And what we've seen is time and time again, developers, system administrators, users, they don't take the time to go and make those changes. And it leads to software that's out in the real world being used that's vulnerable to different types of attacks. So although this may seem like such a simple thing, really thinking through what is the most secure state of the system? What is the most secure way of providing an interface to other developers? What is the most secure way of handling input, especially input that we haven't seen before, where we don't know exactly what category it is or how it fits into our normal flows. The most secure way of dealing with user input that may not be exactly what we want. The most secure way when you just install your app and do nothing else, it should be the secure by default. And we really, really want to do this, because if we don't do it, other users either aren't going to know what the right thing is to do. Other developers aren't going to know the right way to use things, while other developers or users aren't going to take energy to try to overcome and learn how to do the right thing. And the truth is many of us just expect things to be secure out of the box, which isn't necessarily a valid assumption. But you want to try to make sure that it is for your app. You don't want people to assume that it's secure and then realize that they've leaked a bunch of their own private data, because they didn't take some action that you expected them to take. So secure defaults is really about thinking through the design of your application and its implementation. So that in every line of code, in every configuration setting, in every installation decision, whatever you're doing, if the user, or the developer, or the system administrator, or whoever it is, does nothing else, they will get the security right. You want to make people work to remove security, to do things in the wrong way. And if you make it so it takes energy to do the wrong thing, you're much less likely to have users, system administrators, developers, or others going and comprising the security of your application, or accidentally leaking their own data.
