Don’t use addslashes for database escapes

November 30th, 2007 by Ivo

On a regular basis, I still encounter the following conversation:

"What do you do against SQL injection?"
"I escape the data."
"How?"
"addslashes"

This is not the best way to escape data. The most important reason is security. addslashes can lure you into a false sense of security. As Chris Shiflett points out, there are situations that addslashes doesn't escape.

Use mysql_real_escape_string instead.

When using a different database, such as Oracle, addslashes won't help either: the single quote escape for MySQL is ', but for oracle it's '' (a double single quote). For each database there is an alternative to mysql_real_escape_string.

An even better way to handle this problem is to use prepared statements, for example with PDO. PDO uses prepared statement capabilities of the database if supported, or emulates it when it isn't supported. In a prepared statement, it is a lot harder to exploit SQL injections.

Many people know about the disadvantages of addslashes, and it's even covered in the ZCE exam, but still a lot of people use addslashes. Probably one of the main reasons is that the documentation at php.net still states this:

An example use of addslashes() is when you're entering data into a database. For example, to insert the name O'reilly into a database, you will need to escape it. Most databases do this with a which would mean O'reilly."

The comments in the manual mention the problems, but many developers will not read those.

So even if this is old news, it's good to draw attention to it every once in a while.

8 Responses to “Don’t use addslashes for database escapes”

  1. November 30, 2007 at 9:08 am, stefan said:

    Just to add to this: if you’re using mysqli instead of mysql, don’t forget to use mysqli_real_escape_string() :)

  2. November 30, 2007 at 3:37 pm, Mike Girouard said:

    I don’t think that the PHP community can write about this enough. I believe that features like magic_quotes_gpc and functions like addslashes() can create a false sense of security — which oftentimes is more harmful than good.

    Instead, clear-cut teaching of best practices (FIEO for example) is the way to go, IMHO.

    PS your captcha is killing me…

  3. December 02, 2007 at 3:48 pm, till said:

    Or if you are using one of the many classes (PEAR::DB, PEAR::MDB2, Zend_Db, etc.) for DBAL there is always a quote() method. :)

  4. December 03, 2007 at 9:04 pm, PHPDeveloper.org said:

    Ivo Jansch’s Blog: Don’t use addslashes for database escapes…

    Ivo Jansch has a reminder for developers when they’re putting user ……

  5. December 03, 2007 at 11:24 pm, developercast.com » Ivo Jansch’s Blog: Don’t use addslashes for database escapes said:

    [...] Jansch has a reminder for developers when they’re putting user data into their databases – don’t use [...]

  6. December 04, 2007 at 4:09 am, Don’t use addslashes for database escapes | eKini Web Development Blog said:

    [...] jansch.nl: This is not the best way to escape data. The most important reason is security. addslashes can [...]

  7. December 04, 2007 at 10:23 am, open source cms said:

    Use PDO with bind!

  8. February 03, 2008 at 5:29 pm, Brian Reich said:

    Or use Zend_Db Row data gateways. This design pattern makes database access stupid simple.