This aspect to PHP security means that we don't just look at blocking those things which are potential security issues. Instead we block everything except those things which validly need to be allowed.
What this means is that when you are writing your code you need to be thinking about what should specifically be allowed and block everything else rather than thinking what should specifically be disallwed and to allow everything else. To a large extent this means that you don't need to be thinking about what sorts of things might be harmful in order to block them but insterad should be thinking about what needs to be allowed and to block everything else whether it is potentially harmful or not.
When setting up the files your script will access you should only give write access to files that you expect the script to be able to update. Any files that don't need to be updated should only have read access available. If at some future time you decide to add a way that the file can be updated from a script then you update the file access allowed at that time to allow writes.
Perhaps the situation where this principal is most obvious is if you set up a password protected area where different people are required to be able to perform a variety of different tasks. In designing such a system you need to consider just exactly what combinations of tasks that each person needs to be able to perform and set it up so that you can specifically allocate the required access level to correspond to what each person needs. By limiting the number of people with access to a given script you limit the exposure of any as yet unidentified security holes in that script. If it turns out that someone needs access to additional functionality in the future then you can update their access level at that time.
In the case of field validations it is going to be impossible in most cases to validate fields so that only valid values can be input (for example if you validate that first names are only allowed to contain letters of the alphabet then someone could still enter Xxxzxxx which is extremely unlikely to be an actual name, if you validate an email address you can validate that it is correctly formatted to be a possible email address but not if it actually exists). Any field validations are compromises between the complexity of the validation process and the attempt to eliminate what isn't valid. In the case of someone's first name validating that it is only letters is a reasonable compromise because anything more specific would require a list of all the possible first names that exist. Validating the first name to just eliminate those characters that present potential security holes is not an appropriate validation since not only does the lower level of validation mean that there is a far greater potential for garbage to get through the validation but also you may have missed thinking about some potential security hole that involves using different characters from those that you have specifically blocked as representing known security issues. If it is discovered that allowing spaces and hyphens in the first name exposes a potential securitry hole where the name is being passed to a separate program as a parameter where a space followed by a hyphen would trat what follows that as another separate parameter to that program then there is no security issue that needs to be resolved if those characters are already considered to be invalid for that field.
By limiting what is allowed as much as is reasonable in the first place and only changing things to allow something extra when it becomes necessary that the something extra be allowed, you reduce the opportunities for unidentified security holes. If the particular access is not allowed in the first place because it is not needed (Joe doesn't need access to create new users and first names don't need to be able to contain spaces) then any security issues that you discover later are going to be less damaging (the only people who could exploit a security hole in the add user screen are you and Mary since only the two of you can even access that screen and security holes involving spaces in user names can't cause issues because spaces are not valid to start with). Either the security hole can never exist in the first place or the access to be able to exploit it is limited and so the chances of someone actually exploiting the hole before you fix it is relatively minor.
Restrictions on access also help to limit the damage that can be caused if someone finds a way past some of your security. Managing to break into Joe's account wouldn't give someone access to create their own user account if Joe doesn't have access to that option.
This article written by Stephen Chapman, Felgall Pty Ltd.