About the Author

Chris Shiflett

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


OWASP, the Open Web Application Security Project, is famous for its Top Ten list of security vulnerabilities. David ported the list to PHP (PHP and the OWASP Top Ten), and now OWASP has released its own PHP-specific list, the PHP Top 5:

The PHP Top 5 is based upon attack frequency in 2005 as reported to Bugtraq. This information is a valuable insight into the most devastating attacks against the world's most popular web application framework.

In 2005, OWASP collaborated with SANS to research and write a completely new PHP section to their successful Top 20 2005. The OWASP PHP Top 5 is the full unabridged text, updated to reflect recent XSS attacks and SQL injection vectors.

The top five concerns for PHP developers, according to this research, are:

  • Remote Code Execution
  • Cross-Site Scripting
  • SQL Injection
  • PHP Configuration
  • Filesystem Attacks

Remote code execution (also called remote code injection or code injection) should see a reduction in popularity in PHP 6. The following list of changes is from the PHP 6 meeting notes that Derick posted:

  • We split allow_url_fopen into two distinct settings: allow_url_fopen and allow_url_include. If allow_url_fopen is off, then allow_url_include will be off too.
  • We enable allow_url_fopen by default.
  • We disable allow_url_include by default.

SQL injection could also see a reduction in popularity if more and more developers start using PDO and its support for prepared statements. From the manual:

Prepared statements are so useful that they are the only feature that PDO will emulate for drivers that don't support them. This ensures that you will be able to use the same data access paradigm regardless of the capabilities of the database.

Thanks, Wez!

About this post

The OWASP PHP Top 5 was posted on Fri, 07 Jul 2006. If you liked it, follow me on Twitter or share:


1.Kevin said:

You are 100% correct about using prepared statements, however, one problem I have noticed with PDO is that PDO::query(statement) will prepare every statement (IOW, why bother having a PDO::prepare() method?). This causes a problem (with MySQL at least) with databases that cannot prepare DDL statements (CREATE, ALTER, ...). While most applications will never need to execute these, it is a serious problem for writing automation scripts and similar.

Fri, 07 Jul 2006 at 13:06:27 GMT Link

2.Jakub Vrana said:

As long as allow_url_fopen (or allow_url_include) will not disable php://input, it has nothing to do with security. Disabling allow_url_fopen will discourage script kiddies trying to open index.php?file=http://... but not real hackers opening index.php?file=php://input and passing PHP script to the input.

Fri, 07 Jul 2006 at 13:12:36 GMT Link

3.Chris Shiflett said:

You're right, but every step in the right direction reduces the popularity of an attack. Other attack vectors exist, but I don't think it's accurate to say that this has nothing to do with security.

Disabling register_globals is an example of a step in the right direction, and there are plenty of attack vectors not prevented by that. :-)

Fri, 07 Jul 2006 at 13:56:49 GMT Link

4.Stuart Herbert said:

Unfortunately, it's far too soon to recommend PDO for use in production environments. PDO currently doesn't manage its resources well, leading to segfaults and excessive memory use.

And then there's the on-going issue (mentioned frequently during php|vikinger) of PDO's poor performance compared to the mysql extension :(

Best regards,


Fri, 07 Jul 2006 at 14:50:07 GMT Link

5.metapundit said:

PDO is eventually going to be the way to go, but in the meantime if you're stuck on shared hosting (or whatever) you can use PEAR::DB (or it's successor PEAR::MDB2) for prepared statements. I personally find some of the convenience functions highly useful for writing less code (getAssoc, getOne, etc) but even if the only benefit was preventing SQL injection, it would be worth it...

Sat, 08 Jul 2006 at 01:58:38 GMT Link

6.Jakub Vrana said:

Disabling register_globals is a way how to protect poorly written script against certain type of attack. Disabling allow_url_fopen is a way how to protect poorly written script against unexperienced attacker, not the attack itself.

Sat, 08 Jul 2006 at 08:56:45 GMT Link

7.Harry Fuecks said:

Why htmlentities over htmlspecialchars (http://www.owasp.org/index.php/PHP_Top_5#How_to_Protect_Against_It_2)?

As I see it, htmlentities is likely to cause problems if you're generating anything claiming to be XML (are the entities defined?) plus might break character encoding, depending on how a page is encoded e.g. blind use of htmlentities, without charset identification argument + UTF-8 (and if UTF-8, why use character references anyway, given native Unicode character representation?).

Does htmlentities offer any particular security advantage?

Mon, 10 Jul 2006 at 21:10:12 GMT Link

8.Narada said:

The PDO API and the concept behind it absolutely rock. However, I agree with Stuart too. My biggest problem with PDO is that when, on numerous occassions, I have come across problems and filed them as bugs they are very slow to get any attention. Currently PDO greatest limiting factor for me, after the reproducible segfault, is the fact that I cannot fetch multiple result sets from a mysql stored procedure. This too is filed as a bug and is still awaiting any feedback.

Tue, 01 Aug 2006 at 11:16:33 GMT Link

Hello! What’s your name?

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