I used to write CAD system software (many moons ago), and when doing so I used what I call "defensive coding techniques". Which meant that I never trusted user input, that a file would be available, that I could write correctly to a device - I tested, tested and tested again. In our environment, it made huge sense. The application had to be installed on a wide variety of machines and be self configuring, and to report back in layman's terms about any problems. User inputs - typically made by draughtsmen who were excellent in their filed but very new to computers - had to be tested for the right type of content, and sensibility too. And checks had to be made on system resources to make sure that they really were available. It was no good just pouring the output to a pen plotter onto an RS232 port on which the plotter was switched off or off-line or out of paper - a meaningful trap and error message was needed.

So why is it that I see so many PHP web applications written in a non-defensive manner, and indeed I write non-defensive PHP pages myself?

* Web applications in PHP are running for hundreds or thousands of users on a single server, so the issues of installation and resources on lots of individual machines do not apply

* There are far few inputs to a PHP page, and it's running as a "batchlet", so that the inputs are far more controlled and easily validated

* There is no need to defend agaist array overruns due to dynamic memory allocation; the power of the computer is used to eliminate from within the language things that the authors of code have had to do for themselves for years.

* Modern language have far better error trapping and handling built in to them. So that although error conditions need to be checked, it's done at a very much higher level

* With PHP code being writeable so much faster than traditional code, you're working with a much smaller developer team - perhaps just one person where there would have been 3 had you been using C or Fortran. So there's no need for you to have as much testing and checking at the interface between various parts of your system - they're an individual's call to another of his functions and not a possible API misunderstanding between to members of a team

* With huge numbers of users on a single instance of the code, any error will be reported and shake out quickly; if the absence of defensive code leads to a problem it will be seen by a higher number but a lower proportion of users - soreported faster, but less upsetting to the user community.

You may not agree with all of the above, but look at each carefully and it's a justification for not writing code as defensively in PHP as you would have in C++.

My personal view?

There is no need to code as defensively as you would have done in the past os projects that (in PHP) are quite small - BUT - you should remember that when you develop what you think will be a small application, it's likely to end up turning into something bigger. And that you might want to share code later in which case a few extra checks and balances may be no bad thing.

And you should ALWAYS secure your PHP application against injection attacks!

---

OK - Let's answer that "the other way around" ;-)

Put another way, you should take a step back and when you right code you should decide WHAT you're defending against. And in a web / PHP environment it's different to what it was in a traditional coding environment!

You MAY be able to ease up on some of the traditional "defences" but you need to add things like ...
• Injection Attack considerations - technical (<, ", ' \ and space characters, file names that start / or ../, etc)
• Injection of undesired content (malicious and silly sign ups, content into anything that manages content such as blogs, forums)
• Action to ensure that the HTML you generate is high quality / always to standard - helps avoid browser dependency issues
• Issues with login systems / cookies / account hijacking
• User documentation issues - your users on the web are unlikely to call you if they can't understand how to use the site, where such issues would have been picked up during training on the CAD system
• Tests to ensure that robots (some of which are malicious) can't do large scale damage.
• protect code against installation on systems which may have register_globals on, or magic_quotes off, or short_tags off - which can make a difference to the source code.
• allow for system changes later - PHP4 to PHP5 if you copy objects, and modules such as mysql -> mysqli (or perhaps sqlite in the future?)
(written 2008-07-02)

 H117 - Security in PHP
  [345] Spotting a denial of service attack - (2005-06-12)
  [426] Robust checking of data entered by users - (2005-08-27)
  [920] A lion in a cage - PHP - (2006-11-10)
  [947] What is an SQL injection attack? - (2006-11-27)
  [1052] Learning to write secure, maintainable PHP - (2007-01-25)
  [1086] Injection attacks - safeguard your PHP scripts - (2007-02-20)
  [1323] Easy handling of errors in PHP - (2007-08-27)
  [1387] Error logging to file not browser in PHP - (2007-10-11)
  [1396] Using PHP to upload images / Store on MySQL database - security questions - (2007-10-19)
  [1482] A story about benchmarking PHP - (2007-12-23)
  [1542] Are nasty programs looking for security holes on your server? - (2008-02-17)
  [1679] PHP - Sanitised application principles for security and useability - (2008-06-16)
  [1747] Who is watching you? - (2008-08-10)
  [1779] Injection Attacks - avoiding them in your PHP - (2008-08-31)
  [2025] Injection Attack if register_globals in on - PHP - (2009-02-04)
  [2628] An example of an injection attack using Javascript - (2010-02-08)
  [2688] Security considerations in programming - what do we teach? - (2010-03-22)
  [2939] Protecting your images from use out of context - (2010-08-29)
  [3210] Catchable fatal error in PHP ... How to catch, and alternative solutions such as JSON - (2011-03-22)
  [3698] How to stop forms on other sites submitting to your scripts - (2012-04-15)
  [3747] An easy way to comply with the new cookie law if your site is well designed - (2012-06-02)
  [3813] Injection Attacks - PHP, SQL, HTML, Javascript - and how to neutralise them - (2012-07-22)
  [4642] A small teaching program - demonstration of principles only - (2016-02-08)

H115 - Designing PHP-Based Solutions: Best Practice
  [123] Short underground journeys and a PHP book - (2004-11-19)
  [237] Crossfertilisation, PHP to Python - (2005-03-06)
  [261] Putting a form online - (2005-03-29)
  [340] Code and code maintainance efficiency - (2005-06-08)
  [394] A year on - should we offer certified PHP courses - (2005-07-28)
  [563] Merging pictures using PHP and GD - (2006-01-13)
  [572] Giving the researcher power over database analysis - (2006-01-22)
  [839] Reporting on the 10 largest files or 10 top scores - (2006-08-20)
  [896] PHP - good coding practise and sticky radio buttons - (2006-10-17)
  [936] Global, Superglobal, Session variables - scope and persistance in PHP - (2006-11-21)
  [945] Code quality counts - (2006-11-26)
  [1047] Maintainable code - some positive advice - (2007-01-21)
  [1166] Back button - ensuring order are not submitted twice (PHP) - (2007-04-28)
  [1181] Good Programming practise - where to initialise variables - (2007-05-09)
  [1182] Painting a masterpiece in PHP - (2007-05-10)
  [1194] Drawing hands on a clock face - PHP - (2007-05-19)
  [1321] Resetting session based tests in PHP - (2007-08-26)
  [1381] Using a MySQL database to control mod_rewrite via PHP - (2007-10-06)
  [1389] Controlling and labelling Google maps via PHP - (2007-10-13)
  [1390] Converting from postal address to latitude / longitude - (2007-10-13)
  [1391] Ordnance Survey Grid Reference to Latitude / Longitude - (2007-10-14)
  [1487] Efficient PHP applications - framework and example - (2007-12-28)
  [1490] Software to record day to day events and keep an action list - (2007-12-31)
  [1533] Short and sweet and sticky - PHP form input - (2008-02-06)
  [1623] PHP Techniques - a workshop - (2008-04-26)
  [1794] Refactoring - a PHP demo becomes a production page - (2008-09-12)
  [2199] Improving the structure of your early PHP programs - (2009-05-25)
  [2221] Adding a newsfeed for your users to a multipage PHP application - (2009-06-06)
  [2430] Not just a PHP program - a good web application - (2009-09-29)
  [2679] How to build a test harness into your PHP - (2010-03-16)
  [3539] Separating program and artwork in PHP - easier maintainance, and better for the user - (2011-12-05)
  [3820] PHP sessions - a best practice teaching example - (2012-07-27)
  [3926] Filtering PHP form inputs - three ways, but which should you use? - (2012-11-18)
  [4069] Even early on, separate out your program from your HTML! - (2013-04-25)
  [4118] We not only teach PHP and Python - we teach good PHP and Python Practice! - (2013-06-18)
  [4326] Learning to program - comments, documentation and test code - (2014-11-22)
  [4641] Using an MVC structure - even without a formal framework - (2016-02-07)
  [4691] Real life PHP application using our course training MVC example - (2016-06-05)

Back to July to December 2008 - Open Source training schedule

Previous and next or Horse's mouth home

Forward to Lua Course - here is the index

Dealing with The Press
Sorting in lua - specifying your own sort routine
Saying NOT in Perl, PHP, Python, Lua ...
Lua Course - here is the index
Defensive coding techniques in PHP?
July to December 2008 - Open Source training schedule
Towards Object Oriented Programming in Lua
Co-routines in Lua - co-operative processing
Conversion of c/r line ends to l/f line ends
Some sideways thoughts on the news