About the Author

Chris Shiflett

Hi, I’m Chris: entrepreneur, community leader, husband, and father. I live and work in Boulder, CO.

PHP Insecurity

Andrew van der Stock has written a strong criticism of PHP's insecurity. Andrew is a seasoned security expert and a major contributor to OWASP, and he states:

After writing PHP forum software for three years now, I've come to the conclusion that it is basically impossible for normal programmers to write secure PHP code. It takes far too much effort.

He continues, citing specific areas where he thinks PHP is weak and asserting that "PHP must now mature and take on a proper security architecture."

Many of the insecure features he cites (register_globals, magic_quotes_gpc, and safe_mode) are slated to be removed in PHP 6, but his core complaint seems to revolve around the fact that PHP makes too much power too easily accessible, often granting developers more power and flexibility than they realize (e.g., wrappers).

Aside from minor language features like taint mode, I don't see what other platforms offer to help prevent inexperienced developers from writing insecure code. Anyone care to enlighten me? :-)

About this post

PHP Insecurity was posted on Mon, 23 Jan 2006. If you liked it, follow me on Twitter or share:


1.Ilia Alshanetsky said:

So to summarize Andrew's points:

* Most programmers are inept.

* Languages should be designed to protect developers against themselves.

* Functionality is bad because people can't be trusted to use it.

* Simple is bad, because it allows people to write code without getting a PHD.

Mon, 23 Jan 2006 at 17:36:19 GMT Link

2.Sean said:

Most of the time I hear complaints like this, the complainers just don't know PHP well enough.

For example:

13:11 < h****r> and tell whoever you know at php that we need "use strict" ! :o)

13:12 < scoates> define "use strict" in the context that you want it?

13:12 < scoates> a taint model?

13:14 < h****r> scoates> use strict; comes from perl ( http://www.perl.com/doc/manual/html/lib/strict.html )

13:14 < scoates> h****r: but what do you actually need?

13:15 < h****r> strictness, you can easily make mistakes in php. Unitialized variables are a good example.

13:16 < scoates> h****r: accessing an uninitialized variable will raise an E_NOTICE

13:16 < h****r> $ php -r 'echo $var;'

13:16 < h****r> Notice: Undefined variable: var in Command line code on line 1

13:16 < h****r> oh my god

13:16 * h****r check is php.ini

13:16 * d***s larts h****r

13:17 < scoates> your error_reporting level was too low (-;

13:18 < h****r> hmm i got E_ALL ;)

13:18 < scoates> yes.. it's a bitfield, so E_ALL includes E_NOTICE

13:18 < scoates> (but not E_STRICT)

13:18 < h****r> anyway, overall i like php. I am mainly missing some strictness and perl's =~ :o)

The same is true of any language: I can write some perl, but I can't write it WELL. I don't know how to do things PROPERLY.


Mon, 23 Jan 2006 at 17:37:25 GMT Link

3.Richard George said:

Every time I hear this argument it boils down to the fact that PHP's easy to use; newbies can use it, newbies write insecure code, therefore PHP is insecure. Now, given that level of logic, I'd hate to see the code these people create in *any* language.

BTW Chris, I just finished reading Essential PHP Security - glad to say I already knew most (albeit not all) of it but will be recommending it highly, despite a couple of omissions, and will be following this blog closely.

Mon, 23 Jan 2006 at 19:38:28 GMT Link

4.Chris Shiflett said:

Hi Richard, welcome to the blog, and thanks for the kind words. :-)

Mon, 23 Jan 2006 at 20:28:51 GMT Link

5.Christopher Kunz said:

I absolutely agree. We discussed that blog rant on IRC today, and so far I can't think of any reasonable measure that the language itself could take to avoid users shooting themselves in the foot - apart from not being newbie friendly.

A "beginner mode" is a pathetic idea IMHO, and all the important stuff is gonna happen in PHP 6 anyway. I'd like to see a thorough implementation of tainted mode in PHP, but then again... we all know what happened with the thorough implementation of Safe Mode and open_basedir... ;)

Mon, 23 Jan 2006 at 20:40:35 GMT Link

6.Derick Rethans said:

One solution to all your problems: http://pecl.php.net/filter

Mon, 23 Jan 2006 at 20:53:49 GMT Link

7.Matthijs said:

I think it's too easy to blame the language itself, or the inexperienced newbies. Because, if you think about it: how do these beginners learn to program? For a large part by reading articles and tutorials online. And how should they learn about security if security issues are not even mentioned in these articles? Even on well respected websites? And even if security is discussed, it's not done well enough (remember your critique on a sitepoint article recently?)

It wasn't untill I read books from Chris and Ilia that I started to realise how little attention is given to security. Even if an author of an article is very well aware of issues, they (often) do not mention it. Sometimes when I reply to articles and bring forward the fact that there could be security problems using a script, authors reply: "O yes, of course, you should add some input filtering".

So my 2ct: keep writing about security in php, Chris (and others).

Mon, 23 Jan 2006 at 22:05:35 GMT Link

8.elias said:

ack Matthijs. currently secure web apps are not possible with no knowledge about security. the only solution is to be aware of 'security'. its on the knowing to keep the topic up and get it in the newbies head.

Tue, 24 Jan 2006 at 00:03:42 GMT Link

9.Andrew van der Stock said:

Hi everyone,

Thanks Chris for highlighting my blog entry. :)

I am currently working on PHP code snippets for the OWASP Guide 2.1, and so PHP will be a first class language in the hard copy version of the OWASP Guide along with J2EE, .NET, and ColdFusion (a senior security person at Macromedia contributed a large quantity of snippets and advice).

It's now been nearly a month, and no response from Rasmus. Is there an official way of contacting the PHP project? I still feel that it would have been nice to have been contacted back, like "I'm not the right person, please talk to ..." or "please post to ..." but no reply is just rude. Anyway, enough on that matter.

My blog entry argument is not

Programmers use PHP

=> PHP has many insecure features

=> PHP is insecure


Newbie programmers use PHP

=> Newbie programmers know nothing about security

=> PHP is insecure

Although these are both symptoms of a larger malaise.

My root cause argument is:

(Observed Fact) Bugtraq is littered with literally thousands of unsafe PHP applications, far more than equivalent languages/frameworks

(Hypothesis) The PHP project made decisions which makes it harder than it should be to make safe applications. Many of these decisions affect newbies more than advanced programmers or those with a security bent. All PHP programmers are hampered by slow adoption rates of newer PHP versions which *have* safer interfaces.

=> So what do we need to do to make PHP safer?

The slow adoption rate is, in my humble opinion, due to incompatibilities introduced by PHP 5.0 fixing design faults from earlier bad decisions made in PHP 3 and 4 as well as many unnecessary changes.



Hosters will not move to PHP 5.0 until the vast overwhelming majority of PHP applications run on it, and most programmers need to write to PHP 4.x as 5.0 apps will not run on most hosting sites. Maintaining two code bases is a lot of work, so it doesn't happen, and therefore most apps are still PHP 4.x to this day.

Large scale PHP applications, which could use extensions like PDO, are further hampered due to the difficulty in installing and using PECL and PEAR modules in a supported way on pretty much all common hosting environments*.

I *want* PHP to be safer. I *want* to help the PHP project, by reviewing their design and architectural decisions, and suggesting improvements if they'll have them. If they do not have a fully formed security architecture, I'm prepared to help design one.

However, if we go too far, PHP 6.0 will have an even slower adoption rate than PHP 5.0 has had, and all the good work in making a safer language might be wasted. Therefore, careful changes are required to minimize the impact and to encourage hosters to upgrade.

In a sick sort of way, I think the only thing which might help is also a really bad outcome: PHP 4.x is becoming such a nightmare to secure and host, it could end up being banned. I know most hosters have a list of banned PHP applications and prohibited versions. I feel it will only take each hoster to lose control of their servers one time too many for severe action to be taken. A known safe version may be the answer, a version which will not run unsafe code. I hope it doesn't come to this.

Hopefully, this blog entry will help raise the issue, and with some luck we can start improving PHP security at the root, rather than on the edges. My blog entry discusses the idea of a unified security architecture for PHP. I hope that PHP 6.0 has something like that, or at least will take advice from us and make it so.


* I've never had a shared hosting environment (ie CPanel, etc) where I could request for a PEAR module to be installed, even today on my dedicated host. Unlike 99.9% of shared hosting users, I have access to a shell prompt, but I still cannot install PEAR or PECL modules as I don't have root. Without a simple solution to installing PEAR / PECL dependancies without disrupting any other shared user and without needing root, these excellent code gems are useless - you have to copy and paste them into your project.

Tue, 24 Jan 2006 at 01:14:52 GMT Link

10.Chris Shiflett said:

Andrew, thanks for your thorough reply. Regarding email, you'll probably have more luck with the internals mailing list:


All the core developers watch that list, so your email is less likely to be missed. :-)

Tue, 24 Jan 2006 at 02:25:11 GMT Link

11.Andrew van der Stock said:

I found myself responding to the comments rather than Chris' point: what do other languages provide which PHP could usefully use.

1. XSS safe by default

Struts and .NET both make the easiest to use output method XSS safe by default.

<bean:write ...


.NET's web forms have page validation methods, which automatically detect most forms of XSS attack without writing any code.

Sure you can make mistakes in both languages, but I think this is a great first start.

2. Remove intermingled data / query patterns

All injections (SQL and otherwise) are made easier by the fact that it is trivial to write dynamic queries, and non-trivial to write a parser to prevent them whilst still allowing the benefits of dynamic queries.

Look at the Dejection paper presented at last year's Blackhat. This is ground breaking stuff, but it's basically irrelevant.

We need to remove the intermingled interfaces and prevent any new ones creeping in.

3. A wholistic security architecture.

In particular, have a look at ASP.NET's security architecture. By default, it does basically everything right -

* principle of least privilege - it runs with few privileges

* fine grained evidence based security

* coarse grained authZ is easy to hook into Active Directory

* When a feature extends many others, you need to ask for it by Reference, rather than just using it

* It's moderately OO from the get go; there are essentially no functions except for backward compatibility reasons

Now before you go thinking that I am in love with ASP.NET, there are downsides.

It's difficult to do advanced web services security without WSE

Partial trust has a few design holes - look at Dinis Cruz's excellent research for information about this

It can be tricky for newbie programmers to secure the hidden features, like viewstate, which is a minefield for those unfamiliar with ensuring its security

Lastly, larger apps in J2EE have many excellent frameworks to leverage off:

Spring, Struts, Hibernate, etc

PHP has many half hearted attempts and the performance of these leaves a great deal to be desired, so they are not used. I'm thinking Mojavi, WASP, PRADO, etc.

The reason I mention these frameworks is simple. In my experience, the security issues tend not to come from the Java or interfaces, but from the use of design patterns used blindly to implement simple business processes. This leads to process tampering issues, like being able to enter -1 as a quantity, etc, rather than direct injection attacks. Moving the attack upwards would eliminate script kiddies for some time.

Lastly, none of these really help if the programmer doesn't Think Evil. I've seen many J2EE applications which did far worse things than XSS attacks or SQL injection attacks. Such basic attacks are sooooo 1990's. Now it's about organized crime and motivated attackers earning their keep from fraud and extortion. That's the next horizon in my research - security architectures for everyone.


Tue, 24 Jan 2006 at 02:34:25 GMT Link

12.Greg Beaver said:

As a side note, the comment about not being able to install PEAR without root is blatantly incorrect.

Andrew: you can use wget to download http://pear.php.net/go-pear


php go-pear local

This will automatically attempt to install a local copy of PEAR.

If you have PHP 5, then wget http://pear.php.net/go-pear.phar and simply:

php go-pear.phar

And choose local over system. Save your pear.ini as ~user/.pearrc

At this point, if your host has not upgraded PEAR to 1.4.x, you can simply create an alias to ~user/pear/bin/pear

I've been doing this quite successfully for years on several shared hosts. There are also many easy ways to install PEAR remotely, RTFM.



Tue, 24 Jan 2006 at 06:03:38 GMT Link

13.Andrew van der Stock said:


The problem is most shared hosting providers, particularly the free ones, users do not have shell access, and often all forms of system() are blocked, and safe mode is enabled.

Look at the first few lines of the go-pear script. Nearly all of those functions (set_time_limit(0), fopen, etc) are restricted in safe mode.

Therefore, if you are vBulletin or phpBB, you do not rely on PEAR or PECL as most of your users - who often struggle to install the product even with easy to use installers have no hope of satisfying such dependencies.

This is what I was referring to. I use PEAR and PDO on my own scripts for me, but I do not rely upon them being available in my forum software. To do so would be death.



Tue, 24 Jan 2006 at 06:32:28 GMT Link

14.Quinton Parker said:

My 5c... anybody listenin?

The problem with PHP security is "other developers". The irresponsible ones who couldnt care less about doing things right from day one. They should switch to .Net and other languages that cover their asses.

Too many phpers are content to write code that "runs" and does the job albeit poorly.

I've seen enuff spagetti and i'm tired of it... Resource hungry scripts screaming hundreds of errors/warnings. Encapsulation constantly broken by global variables and register_globals appearing out of thin air. Aaarargghg

To me its a no-brainer. I dont worry (too much) about PHP security due to my strict coding style and adopted best practices from the likes of Chris Shiftlett, Harry F, Jason E. Sweat...

The Zend Certified Exam recognises PHP proggies. Great! How about a cert that goes a step further to recognise the responsible ones?

Say a Zend Professional Engineer?


ZPE ;-)

Tue, 24 Jan 2006 at 07:23:43 GMT Link

15.Dagfinn Reiersøl said:

"Struts and .NET both make the easiest to use output method XSS safe by default."

So how about the popular PHP template engines?

I don't know everything about Smarty, but from looking at the docs it seems I may have to do something like this to output the variable $xss_risk safely if I haven't escaped it beforehand:


On the other hand, my favorite template engine PHPTAL seems to do this by default. :)

Tue, 24 Jan 2006 at 13:29:58 GMT Link

16.AJ said:

The great thing about the PHP community is that we can actully have a debate on this topic.

Look its this simple, I want to write secure apps, I do my damdest everyday to write apps that are secure, however if other parts of the tool I am using are letting me down, well then they need to be fixed.

That being said, I do agree that in general, apps that are created by inexperienced users of the language are where a large portoin of the problems with security happen. But there is also a problem with lazy developers.

Also I do agree that the language, while having a very small learning curve in relation to doing most things, does not make it as easy to constantly escape user imput. Yes filter is being worked on, but I was hoping for something I could fire and forget about, filter appears on the face of it to require me to write more... and I am afterall going to do as little as possible if possible, but I still have to be secure.

I suppose what I am saying here, is look, this is not an attack on PHP, indeed it should be welcomed. There are great areas of PHP, but there are some failings too. Some of it is due to people not understanding how to write stuff securily, and perhaps that is our responsibility as the PHP Community to help our fellow PHPers. But we as PHPers would like that task made easier, by having the toolset made as simple as possible for all, new or old users.

As a side not, I don't write anything in PHP4 anymore, it just 5 now, but I do agree, large scale changes, even if they don't acutally impact on many apps, if reported in a negative manner will not help the rate of adoption. Anyhow, sorry about the rant, have a ggod night.

Wed, 25 Jan 2006 at 00:11:13 GMT Link

17.NOtesGuy said:

I don't think a beginner mode is a good idea either. However, as I said in other places, a beginner learning path IS a good idea. This idea is a sort of training path an employee might go through when starting a new job. First you have to go to this class, then that,... If someone, with community agreement (if that's possible) would put together a short list of reading or links to read to bring a newbie up to speed, that would be ideal. When I was a PHP newbie several years ago, that would have helped TREMENDOUSLY. I am now a newbie in another technology and fortunately I found a book that everyone agrees is the best place to start fresh.

The idea is most power players in PHP agree to it and post it and remind everyone starting out that this is the place to go for newbies.

This would save beginner php developers from going here for part of the information and searching for 3 days to find the next step, or what they think is the next step.

=> A community agreed upon learning path is my suggestion. It would really help the adoption rate.

Wed, 25 Jan 2006 at 13:26:16 GMT Link

18.Notesguy/webdevguy said:

There is disagreement amonst PHP developers who have faced this $_SERVER[’PHP_SELF’]issue before. What does that tell you about community agreement on other security issues? I think it’s great Chris Schiflett and others are bringing PHP security to the forefront. Until there is one authoritative union or “face”, it will remain an issue because people will be free to disagree with full credibility.

Wed, 25 Jan 2006 at 13:38:53 GMT Link

19.Chris Shiflett said:

Can you elaborate on how people disagree with the $_SERVER['PHP_SELF'] issue?

Although I try to advocate that output should always be escaped without exception, I do wish that $_SERVER['PHP_SELF'] did not have any trailing information:


Every developer I know that uses the bad-stuff-here part gets it with $_SERVER['PATH_INFO'] anyway, so there would be no information loss if this wasn't in $_SERVER['PHP_SELF'].

Just an observation. :-)

Wed, 25 Jan 2006 at 13:42:59 GMT Link

20.Notesguy/webdevguy said:

I first saw the issues (read storm) on sitepoint's PHP blog. Here's the specific article:


that references the discussion about PHP security. one topic was how to handle $_SERVER['PHP_SELF'].

Wed, 25 Jan 2006 at 15:25:53 GMT Link

21.Andrew van der Stock said:

I have posted the basis of my security architecture for PHP 6.0 to my site:


Please read over it. More details will be coming soon.


Fri, 27 Jan 2006 at 07:11:34 GMT Link

22.Chris Conn said:

My personal thoughts:

I've been using PHP for the 1 1/2 years (or so). I'm a very adept C++ programmer, along with HTML/CSS/and some XML.

Security should be part of an initial design, and after that the lower level programmers should be limited to interfacing with the API that was created for the specific project they are working on. Granted this requires that there are 2-3 levels of programming experience.

Interfaces should be designed to facilitate the interactions that the lower level programmers will need. This simply requires communications back/forth between the 2 levels of programmers.

Above all, code reviews (which don't get performed enough ... or well enough), should be commonplace. This will help to alleviate potential security holes in any application (whether written in PHP/C/C++/Java/TCL/Perl/ASP/.NET/etc.

Tue, 31 Jan 2006 at 17:11:41 GMT Link

Hello! What’s your name?

Want to comment? Please connect with Twitter to join the discussion.