Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

Recently on stackoverflow I've seen many discussions that mysql_*_escape_string is deprecated and instead recommending PDO.
The way I've been doing it was to allow only letters and ' in the name field , allowing all the characters in the password field (but then hash it ) and then using mysql_real_escape_string to escape special characters. So I read about mysqli but as I see it is the same as mysql:

Escapes a string of characters.

So what are the security issues in using mysql_* and not mysqli or PDO ?

share|improve this question
up vote 8 down vote accepted

If you use mysql_real_escape_string consistently every time you inject content into an SQL string literal, it's fine, there is no security issue.

However what time has taught us is that:

  • Catching every single place you inject into an SQL string literal is hard. In real world software unescaped cases are sometimes missed, even when the original coder understood SQL-escaping properly. Or raw injections are added later in maintenance. Or escaping is omitted where the coder thinks there is no possibility of special characters being in the string, but then later on something changes and that assumption no longer holds true.

  • Littering your queries with ...'.mysql_real_escape_string($value, $db).'... makes them tedious and difficult to read.

  • People still don't understand the encoding issue that real relates to, and consequently fail to set the charset in the right way (mysql_set_charset(), not bad SET NAMES).

We can spend the rest of time chasing these issues in code written with the mysql extension, or just push everyone to use parameterised queries instead, which work properly without requiring any deep understanding of string processing.

share|improve this answer
Also, while probably not relevant to passwords, mysql_real_escape_string will not protect you against injections where you have numeric fields, since there are no quotes to be escaped. – domen Dec 30 '13 at 15:02
I think the most common misinterpreted aspect is that values escaped with mysql_real_escape_string are only intended to be used in a MySQL string literal. There are often cases where mysql_real_escape_string is used for data that is not put in a MySQL string literal but as something else, like, as an identifier, a keyword, an integer literal, etc. However, this does also apply for parameterized/prepared statements, which can only handle data literals. – Gumbo Dec 30 '13 at 15:38
@Gumbo: yes! Annoyingly there is no actual safe way to escape schema names, but at least parameterised queries will often fail quickly if you try to include a parameter in that position. – bobince Dec 30 '13 at 19:22
@bobince The MySQL reference is quite specific about the syntax of identifiers. And with backtick-quoted identifiers, characters between U+0001–U+FFFF are allowed and single backtick is to be encoded with two consecutive backticks. – Gumbo Dec 30 '13 at 19:33

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.