General security principles - PHP Tutorial

- [Narrator] Let's quickly review the primary security principles. These principles are covered in more depth in the course I mentioned earlier, Programming Foundations: Web Security. The first principle is called least privilege. The principle of least privilege means giving a user account only those privileges that are essential to that user's work and 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 limit which functions are exposed for other code to use. 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 never to 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 as well as to employees, admin users, and contractors. The fourth principle is to expect the unexpected. Security's 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. What might a user try to do? How might users try and get around your security? You want to be creative as you try to expect the unexpected. The next principle is defense in depth. You want layers of defenses, redundant security. Then, if one of your security layers is breached, there's another layer behind it to offer protection. It includes thinking about how your organization's people, technology, and operations can work together to create a secure environment. The next principle is security through obscurity. 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 is a website's log-in form. If a user submits a wrong username and password, saying which one is wrong can help a hacker to find a working username and then find a working password. It's better to keep those clues to yourself. Of course, you don't want to ever depend on security through obscurity alone. It's just one layer of your defense in depth. Allow and deny lists are important security tools. An allow list is a list of what's permitted, and a deny list is a list of what's forbidden. If a database server is only expecting connections from the web server, the IP address of the web server can be checked against an allow list. If a hacker keeps attacking a website, then their IP address can be added to a deny list. These two concepts are opposites, but they're not equal. An allow list restricts most actions by default. A deny list allows most actions by default and only rejects the few that match select cases. Using an allow list is going to be the more secure approach. Last of all, you want to 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. Consider what paths data takes as it travels from a user through the application and into the database and the path that takes back from the database to the application and to the user. Remember our equation: awareness plus protection equals security. We need awareness of an application to know where our points of vulnerability might be. These general security principles are the underpinning that's going to guide the choices we'll make in the upcoming chapters.