General security principles

Let's quickly review the primary security principles. These principles are covered in more depth in the Fundamentals of Programming, Web Security course that I mentioned earlier. The first principle is least privilege. The principle of least privilege means giving a user account only those privileges which are essential to that user's work, nothing more. Users in human resources shouldn't be able to see accounting information, and users in accounting shouldn't be able to see human resources information. But we're not just talking about user privileges. Code has access privileges too.

Code should be limited in what it exposes and what it accesses. In object-oriented programming, this means controlling the visibility of class variables and functions. For example, if a function in a PHP class object is only used by that class object, then it does not need to be callable from outside the class. The second principle is that simple is more secure. The larger and more complex that a system becomes, the harder it becomes to secure it. Larger systems have more areas of concern and more complex systems increase the likelihood of bugs or making mistakes.

The third principle is to never trust users. You should be paranoid. Most users aren't hackers, but some are, and it's tough to tell the difference. That applies to the general public primarily, but you also need to use caution with employees, admin users, and contractors. The principle of least privilege can help you here as well and you need to use caution offline as well as online. If you put a lot of effort into securing your site, but then you email a password to someone, back up your database to a thumb drive, or leave your computer logged in overnight, you end up circumventing all of your security efforts.

The fourth principle is to expect the unexpected. Security is not reactive. Our goal is to try and prevent the crime before it happens. In order to do that, you're going to want to consider all the unexpected things that might happen. You'll want to consider what we refer to as edge cases. What are all the possible things that a user might try to do? What are the ways they might try and get around your security? You'll want to get creative as you try to expect the unexpected. The next principle is defense in depth. This is basically layered defenses, redundant security, making sure that if one security mechanism gets circumvented, there's something else behind it that also will help you be protected.

You want to make sure that you think about your people, your technology, and your operations inside the organization and how all three of those can work together to create a secure environment. The next principle is security through obscurity. The idea is that more information benefits hackers who are trying to get into your site. So you want to limit the amount of exposed information. Limit the amount of feedback that you give them. A good example of this is a website's log in form. You shouldn't tell the user whether or not their username or their password was the incorrect piece of information.

Doing so will allow a hacker to keep trying until they can find a valid username and then start to try and find a valid password. But if you simply tell them there was no match, then they don't have any idea which one was the wrong piece of information. For security,, it's important to understand the difference between blacklisting and whitelisting. A blacklist is a reference list for what is forbidden. A whitelist is a reference list for what is permitted. These are opposites, but they're not equal. And the reason why is because whitelisting means restricted by default, and that's a more secure approach.

So in general, if you can, when making the choice, choose to define the things that are permitted instead of just listing the things that are forbidden. And last of all, you'll want to make sure that you map the exposure points and data passageways in your application. Think about the incoming data through URLs, forms, cookies, sessions, and the outgoing data, what goes out to the user as HTML or JavaScript, and consider what paths data takes as it travels from a user through the application and into a database.

Or from the database back to the application and back to the user. Remember our equation, awareness plus protection equals security. We want to have not just awareness of the outside threats that are coming in, we want to have awareness of what our application actually looks like so that we know where our points of vulnerability might be. These general principles are going to guide all the choices that we're going to make in the upcoming chapters.