A lot of my security experienced friends have told me that I need to code my web applications for working under the Suhosin PHP patch, Suhosin being an advanced protection system for PHP installations [...] designed to protect servers and users from known and unknown flaws in PHP applications. Sense stating that feat, I have had to rewrite quite a bit of of my functions and classes. Is this the new standard of making secure web applications so that it is harder to exploit and compromise? Is Suhosin now a common requirement for web development in PHP? 
Should we live by using Suhosin with PHP?
php;web development;web applications
The description on the Suhosin website is pretty clear, emphasis mine:If you are using PHP only for your own server and only for your own scripts and applications, then you can judge for yourself, if you trust your code enough. In that case you most probably dont need the Suhosin extension. [...] Even PHP core programmers are writing insecure code from time to time, because they did not know about a PHP pitfall.Suhosin is one of the ways to mitigate risks related to buffer overflows and similar vulnerabilities. It's not the only way, and it won't magically make your application 100% secure and bug-free.Should every PHP programmer use it? No, because it's an overkill. Personally, I would rather convince every PHP programmer to read and understand OWASP top ten vulnerabilities, and when I read PHP-tagged questions on Stack Overflow for a few minutes, I only hope every PHP programmer will learn what SQL Injection is, and only that would be a big step.For small projects, it doesn't matter. If they are written by a guy who knows what SQL Injection is, great. It's just that there are more important things to do, such as getting the job done or finding actual customers.Large projects are often written by experienced developers who know their stuff and know what are the vulnerabilities and how to avoid them. An additional pair of eyes such as Suhosin won't hurt, but the team has to watch all the pros and cons before adopting it, especially since it may be quite redundant with other techniques. I would prefer my code to be reviewed by a security expert rather than to rely on a tool I didn't even knew the name half an hour ago.Medium-scale projects are where Suhosin may be interesting. Those ones may not be able to afford security experts and skillful developers, so any free tool, would it be a static checker or an extension like Suhosin, may help. At the same time, I would understand the hassle to deploy an additional extension to production servers.Using such extension can also give a false sense of security, especially when you read things like:Always keep in mind that you are not only protecting yourself and your users, but also other people on the internet, that might get attacked by your server after it has been turned into a (Spam-/DDOS-)attack drone.Here is a raw and sloppy estimate of the sources of severe security risks on my customers' servers (non business-critical small to small-to-medium scale web apps):70%: The server is not maintained (example: four years' old version of PHP, never patched despite critical issues discovered since then).15%: I or my team introduced a bug in the web application or used a third-party library which had a bug I haven't noticed.10%: The server hosts FTP, SMTP, DNS, Active Directory, SQL Server 2000, SQL Server 2005, SQL Server 2008 R2, Sharepoint, IIS, Apache and a dozen of other services. Given that nobody knows how to configure the firewall, it was disabled. One day, when this domain controller is hacked, nobody has even the slightest clue what was used by the attacker.1%: There is an exploit in the latest version of PHP, operating system or a popular framework (see Zero-day attack).4%: Something else.Suhosin will help here in maximum 15% of cases, but will give a feeling that I don't have to deal with 95% of possible issues.The same false sense of security may lead to bigger problems:If you are not only running your own PHP scripts but are also hosting 3rd party PHP applications for yourself or even for possible customers, then you cannot trust the code quality of the PHP applications you use.If I don't trust third-party code, I don't use it. Not on my servers. If it's code which cannot be reviewed, such as code written by customers themselves, then it should run in a sandbox anyway, with very restrictive permissions.