Layers of security
A well conceived security system operates on different layers, hence reducing the chance of complete and catastrophic breach when one layer has failed. It doesn’t mean that isn’t still possible, just that the chances are significantly reduced by putting the burden of security on more than one subsystem, on more than one level.
Offers the logistics required to protect your directories and files from (unautorized) access, serving to the outside world only what it is supposed to get. Secure your web server!
By enforcing used-based access, it protects the information you store in databases independently from your file system protection. Secure your database server!
Development environment (PHP)
Specific language configuration settings are designed to reduce security risks (i.e., disabling URL wrappers for file functions). Secure your PHP installation!
This is the singlemost controllable and important aspect of your system’s security. The web server and database server defend themselves – they usually are a product of expert teams, and have been tested and proven in the line of fire. However, they can’t protect themselves from you, because they trust you, and if your code is as such that leaks confidential information or allows attackers to impersonate bona fide users, your system is compromised.
Although completely out of your control, you still have to be aware of various browser vulnerabilities, especially since you won’t be able to avoid writing client-side code, if you’re building a web application.
As noted, an attacker not only must go through this many levels of security to breach your system, but he/she gets this many opportunities to do so. That’s why you should
Distribute the security burden
For example, if you keep encrypted data in a database, store the encryption key on the file system, not in the database. That way, should an attacker steal your data by breaking into the database server, he/she would still have to break into your web server, in order to get the key that would make sense of the data.
Make sure no single layer/component depends on the other to do its job, security wise. Have different admin credentials for your web server administration software (i.e. cpanel) and FTP access, your database server, and your actual system administration interface. That way, if, for instance, your system admin credentials are compromised, the attacker still lacks FTP access.
Levels of security
Not to be confused with the layers of security. It would be wrong to say that some system components require a lower level of security, if compromising those components would allow for systemic security failure. “Levels” of security (plural) make sense in terms of how much would cost (money, time, resources, user experience) to implement any level of security versus how much would be lost without that level of security.
However, in terms of impact on overall security, it is possible to define “levels” of security by the degree of potential damage a breach would cause. For example, take the salt of a hash. It’s perfectly acceptable to store that salt together with the hash itself, so when the attacker gets the hash, they also get the salt. Therefore, they can organize a rainbow table attack against that particular hash, which may or may not succed. It they didn’t know the salt, such an attack would be disabled. In the first instance, knowing the salt decreases security by one level, but in this case the gap is, in practice, negligeable.
Another example: say you don’t allow web login to your system (website), except for system administrators. Therefore, your website does not display a link to the login page, at all. However, the admins know the URL and can access it when they want to login. If an attacker gets hold of this URL, they only just bypassed the security-through-obscurity level of your mechanism, they would still need to deal with your authentication protection.