PHP was initially designed to script web pages with security as one of its primary considerations, however as it can act either as a common gateway interface (CGI) script on the server-side (e.g. run in CGI mode on some servers) or on the client side to generate content for browsers. PHP has become a popular and mature programming and scripting language as evidenced by its use in the world’s most popular open source ecommerce system; osCommerce (and its close competitors). This widespread adoption suggests that there are no significant issues with using PHP in a secure environment, however such open source eCommerce solutions have considered the issues, as Dimov (2001) points out “Regardless of its mode of execution, the PHP interpreter has the potential to access virtually every part of the host — the file system, network interfaces, IPC, etc.” (admittedly some of the flaws Dimov identified have been addressed in subsequent PHP releases) and as such serious thought must be into any newly developed system.
Scripting techniques that can allow the malicious (or inadvertent) user a web system generally involve protecting shared information on the server (e.g. session id), controlling user input and correct PHP configuration in a production environment. The largest risk of these is by far validation of user input to ensure that coding cannot be used in form fields to force errors or displayed to other users for them to run. Such errors, if again not controlled can yield the contents of directories and the location of files in PHP error messages, compromising security (PHP error messages can be restricted as an option to avoid this).
An eCommerce system requires an, at least partial, secure environment to protect personal user data and transactions and therefore it is an accepted standard in eCommerce systems that customer accounts and payment details are covered by Secure Socket Layer (SSL) protocols and that stored data is as secure as possible. Any breech of such protective environments can have catastrophic effects on the eCommerce system owner, by repudiation in law for allowing their system to be compromised, and on the customer by potential financial and privacy loss. The best setup server protection can be compromised by poor PHP scripting through no fault of the PHP system itself, as Dickinson (2005) states “security is a process, not a product” and PHP can be as secure as any other scripting language if used properly.
Dickinson, P (2005) Top 7 PHP Security Blunders [Online]. Available at http://articles.sitepoint.com/article/php-security-blunders (Accessed 3 October 2010).
Dimov, J (2001) On the security of PHP, Part 1 [Online]. Available at http://www.developer.com/lang/php/article.php/918141/On-the-Security-of-PHP-Part-1.htm (Accessed 3 October 2010).