As much as these guidelines, in general, are good there are a few things that are just a little wrong.<p>1. Addslashses is not a good solution to SQL Injection. It might be good to invest in a database abstraction layer, or an ORM that will do prepared statements without thinking twice.<p>2. Strip_Tags is not a solution to XSS. I prefer using something like WMD, Textile, BBCode or Wiki formatting for user input and then kill everything else with fire.<p>3. Removing JS and Flash from output using an RE is not a solution. If you're blacklisting, it probably won't work. These exploits have been around forever. Maybe Anti-Samy can help.<p>4. Referers can be spoofed. Although, this is a good "honesty first" check.<p>5. If you are using crypt, you are doing it wrong. Very, very wrong. After 8 characters, you're practically in plain text.
Blog about website design + blog post about website security = Excellent source of well-intended data that perpetuates PHP code that people think is secure<p>For a better post on securing PHP scripts, see IBM's post at <a href="http://www.ibm.com/developerworks/opensource/library/os-php-secure-apps/" rel="nofollow">http://www.ibm.com/developerworks/opensource/library/os-php-...</a> or just see <a href="http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-real-escape-string" rel="nofollow">http://shiflett.org/blog/2006/jan/addslashes-versus-mysql-re...</a> to understand why anyone recommending addslashes should be ignored.