real_escape() is a function which needs memory for its functionality, so I was wondering if there was any necessity to do that if we've already cast it?

$num = (int) $num;

Can we use real_escape() just for string parameters?

  • 4
    You should never be using functions (standard or not) to escape SQL strings. You should be using prepared statements with something like PDO. Prepared statements cannot be injected. You cannot make a mistake. It's 2012 already and there is no reason to still be escaping SQL strings or values yourself. Commented Jun 6, 2012 at 12:16
  • It's now 2016 and advocating that PDO is much better/more secure than any form of escaping still makes no sense (not saying its worse, just that there are a lot of trade-offs between the 2 approaches, also, even in 2012 these were not the only choices).
    – symcbean
    Commented Jun 28, 2016 at 9:47
  • This is really a question about functionality, not security. Both escaping and casting as int address the problem of SQL injection. However escaping will break the query if the value is not a number and interpolated without quoting. With quoting (and implicit type conversion) the query still breaks for non-numbers. If it's quoted, you may prevent the use of suitable indexes. With casting you will get a value of zero for something PHP thinks does not look like a number. Which is the most appropriate strategy for your application?
    – symcbean
    Commented Jun 28, 2016 at 9:53

3 Answers 3


It's true that casting can mitigate SQL injections, but unless performance is a huge concern for you, I'd use mysqli_real_escape_string() anyway, for two reasons:

  1. Your application might change in the future. Even if your application is only passing integers into your queries right now (via this particular function call or whatever), your code may be modified in the future to accept strings, etc. I'd propose that you're better off planning ahead a bit, and that you should seal off this potential future security vulnerability right now, while it's on your mind.

  2. A less experienced developer might "refactor" away that cast. I can see a junior dev coming through your code at some point and saying, "Why is this cast here? We're only passing IDs into the SQL anyway," and then refactoring away that cast. I'd recommend using mysqli_real_escape_string() even if only to give future developers a heads-up that there's a security issue at stake here.

At the very least, if you're going to rely on a cast to implement security, I'd leave some very conspicious ALL CAPS comments in your code to make it clear that that's what you're doing.

  • makes more sense
    – Alireza
    Commented Apr 16, 2012 at 4:00

You are right. If you know it is an int (because you cast it to int), you do not need to call mysql_real_escape_string().

P.S. I'll go out on a limb and express an opinion. For most purposes, prepared statements are a better defense against SQL injection than manually applying escaping functions. (I'm sure there are PHP folks somewhere who will give me a hard time about this, or point out that some database systems on PHP don't support prepared statements.)

  • thanks for the prepared statement, It's awesome for escaping data, but the problem is performance issues in large scale databases.
    – Alireza
    Commented Apr 15, 2012 at 6:32
  • 1
    Besides prepared statements there are also parameterized statements that serve the same purpose.
    – Gumbo
    Commented Apr 15, 2012 at 8:03
  • 1
    @Sheriff: Performance issues? And you think the escaped version is going to do any better? Commented Apr 16, 2012 at 6:01
  • Don't forget that the old mysql_* functions will be deprecated soon and the PHP developers do not recommend using them. Parameterised queries in MySQLi are the way to go, really.
    – Polynomial
    Commented Apr 21, 2012 at 15:08

In this example - if you cast variable - there is no need to do any other sanitization. But remember that casting must be prepared on the PHP-level. Don't even think about casting in your SQL query!


    mysql_query("SELECT * FROM users WHERE id=".(int)$_GET['id']) 

This one leads to Blind SQL Injection:

    mysql_query("SELECT * FROM users WHERE id=CAST(".$_GET['id']." AS UNSIGNED)")

?id=1 AS UNSIGNED) AND 1337=BENCHMARK(13371337,MD5('ouch!'))--

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .