I agree that the error message should only
be displayed in development. So escaping it should not strictly
be necessary. Escaping it for mysql (mysql_real_escape_string
) would not
be the correct escaping for it in any case.
However, if the query contains HTML markup being written to the database, and the query failed, and you don't escape it using htmlspecialchars
, then it could be difficult to read and interpret the error message. Again, however, this is information only
for the developer and you can always see the raw output using the View Source feature of the browser.
If you setup so errors are displayed during development and logged during production and you use trigger_error
to display/log the mysql error, you would not
want to escape it when it is logged.
My suggestion would be, don't bother escaping it, at all. If, during development
you get a displayed error that looks strange, use View Source to see it in the clear. If you do
escape it, then you have to first check whether you are displaying or logging errors, so you can escape it or not. That would be a waste of programming time and execution resources.
As for the security risk of user injections; again, you are only displaying it during development; so unless you are testing XSS injection attacks, you are not likely to run into any security issues.
If you have properly sanitized/validated the data before you start to use it within your SQL queries then no damage can be done, with the error that is returned.
Not entirely true. The sanitation for the database is different from the sanitation for HTML display. Neither one provides protection for the other.
-- I haven't lost my mind, it's backed up on tape ... somewhere!