Is it safe to display the detailed query in the error webpage with the below details?

**INSERT statement conflicted with the FOREIGN KEY constraint "ABC". The conflict occurred in database ** The statement has been terminated.[INSERT INTO ** ] **

I know that showing this kind of error will help penetration testers and hackers, but I need someone to shed lights on this. How can this information be used for SQL injection or that kind of things? Or is it okay to display such sensitive information?

  • 26
    Well, for one, you expose the details of your database so that attackers can craft attacks specific to your database.
    – schroeder
    Commented Sep 30, 2016 at 6:47
  • Thanks for the comment. So I should block these information right? Commented Sep 30, 2016 at 6:57
  • 9
    Best practice is to prevent these types of messages in production.
    – schroeder
    Commented Sep 30, 2016 at 7:28
  • 3
    Your question's title asks if it is safe, but the question body asks how it can be used for SQLi and friends. Which are you more interested in?
    – user
    Commented Sep 30, 2016 at 11:39
  • 1
    The simplest answer here is that your end user neither cares nor wants to see that error message.
    – pay
    Commented Sep 30, 2016 at 15:31

10 Answers 10


End users should never get to see the gory details of your environment.

Instead it is more professional to show a generic 'Sorry something went wrong' page. At least visitors can see that you have a real error handling mechanism present on your website.

However those errors should be written to the mysql error log and should also trigger a notification by E-mail or otherwise to the IT team. Those errors should not happen so it can be a sign that your site is failing or is possibly under attack.

  • 32
    I'd be careful with email notifications. IF you use them THROTTLE them! My experience is that errors on websites come in bursts, and one of these can overflow your mailbox. Commented Sep 30, 2016 at 10:31
  • 26
    When you log the error you can generate an "event ID". It's safe to show the event ID to the user - and if they end up contacting support, the event ID can be very useful.
    – paj28
    Commented Sep 30, 2016 at 11:49
  • 3
    What paj28 said. Generate a random number/letter sequence every time an error occurs, so they see "Sorry, something went wrong. Error code: XY38734028". Make these unique every time an error occurs. You won't always be given it, but when you do get given one, not only will you find the type of error they got, but you'll be able to find the exact email that was raised.
    – JLo
    Commented Sep 30, 2016 at 12:22
  • 15
    @JLo: But don't call them error code if they're unique per error occurance - "Error Code" brings to mind something the end user can google to see if they can do something on their end, has already been acknowledged, etc. Call it "Error ID" or "Your Support ID" or something that better clarifies that it is a unique, randomly generated code that hasn't existed before
    – Kai
    Commented Sep 30, 2016 at 13:06
  • 1
    In what sense is this answer supposed to answer the question "How can this information be used for SQL injection or that kind of things?", I wonder? It is quite obvious that the subsequent "Or is it okay to display such sensitive information?" means "in the context of information security", you know, what this whole website is about.
    – N.I.
    Commented Sep 30, 2016 at 13:33

No it is definitely not safe because it creates additional SQL injection attack vectors not present otherwise. Example: If you have an SQL injection flow in an insert then this is some kind of "blind" injection because the insert doesn't report back any result rows to the caller. But if you bring a potential insert error message back to the client then you make this vulnerable to the so-called "XPath" injection (see this paper for details). The essence is that you inject an xml function that is supposed to compute a variable of data type xml. One of the function's arguments is an xpath variable which can again be computed by select statements and string concatenation. Instead of providing a valid xpath you do a select (E.g. "select password_hash from users where id='admin'"). So the DB will execute an INSERT that is purposefully wrong through your injection. The result will be an error message like

'bb9af55cd325deaa89bb7b4e36085b4d' is not a valid xpath

If you display error messages like these to the caller this can be used to basically enumerate the DB. I have seen this happening recently. The error message was cut to 30 characters and it was only possible to select one column and one row at a time but still possible to enumerate the entire DB with it.

  • 7
    If seeing log messages creates an attack vector, the possibility of an attack was there all along. Commented Sep 30, 2016 at 13:13
  • 4
    There is a fundamental difference between displaying the error message in the webpage and in logs because the webpage is seen by the same person that is providing the malicious input. Logs are usually only seen by administrators.
    – kaidentity
    Commented Sep 30, 2016 at 13:36

Others have rightfully touched on why MySQL details should not be exposed via the main user interface of a website/application on a production server.

But there is a broader, much more high level issue in play when you display errors to an end user like this:

It basically telegraphs the idea that the server/site is badly managed.

Meaning you are a riper target for hacking not because of the content of the details but because the details have been exposed to begin with.

Your attitude as an application developer—systems administrator and such—is to make your final product can fail gracefully in some way that does not expose the “bones” of the system’s architecture yet still somehow convey some useful debugging data to you.

  • Exactly, even if you somehow determined that there is no security issues, there's absolutely no UX gain in displaying implementation details. Commented Oct 2, 2016 at 18:16

If your application is correctly designed, displaying the text of error messages should not be a security problem. If it was, it would mean that your security relies on obfuscation which is considered as bad practice.

That being said the real question is: what will be the user experience facing messages like that? If your application is meant for average users, they will get an message that bring them no useful information: either they do not understand anything or cannot do anything useful with it. Worse, they could think those lazy devs did not even correctly process their errors - that is what I would think...

That's the reason why the common usage is to display a softer message saying something went wrong, please retry and contact support if the error persists, without the gory details. The full error message should only be displayed when the application is run by the support in a special mode because support techs are interested in the error details.

If you really want to do the nicest job with errors:

  • make sure that you log the error and its context: date-time, user, params of the request, eventually key session data to allow the support to fill a ticket is something must be fixed in the application
  • only display soft external information to the user
  • add a specific way for support to access all the error detail when they are trying to reproduce it - it comes at a cost but will be very appreciated by support techs
  • eventually assign a unique id to the incident and display that to the user

This last possibility only makes sense for high value applications with a limited number of users. That will allow the support to immediately have all the references for the problem when they will be contacted by the user. But it also means that you are ready to answer individually for any error which could be really expensive for normal applications.

  • 1
    If the application was properly designed, the error page wouldn't appear in the first place. :-) Commented Sep 30, 2016 at 14:02
  • 3
    @GeorgeBailey: even a well designed app can face hardware or network problem (crash of a DB server, ...). Anyway well designed does not mean perfect. We all try hard to have no bug in our code, but expecting that no is left would be hubris ;-) Commented Sep 30, 2016 at 14:14

Any technical detail that can be obtained by an attacker can potentially be leveraged to exploit flaws or to get a better understanding of the system (to later on exploit flaws..). In your case it could possibly be leveraged for SQL Injection but it could also allow one to identify your DBMS (if you use native queries with functions proper to MySQL for example), and then test DBMS-specific exploits if the system is not patched.

So to answer the question : no, it is not safe to disclose your queries because doing this increases your security risk.

As mentioned in the comments, the best practice is to hide such information in production environments.

A common practice (for example Maven profiles for Java developers) is to build a project for a specific environment. The "production" profile would have a different configuration that does not show stacktraces on the html responses but only log them in the backend instead.

As a sidenote, displaying technical error messages might also "attract" random attackers that want to hone their skills by hacking any system, as it makes you look like a weak target.


A number of answers have pointed out that it's not best practice to display these errors. However, I'm going to focus on your question: is it safe?

Lets have a look at an example error message. This app is written in Python and Flask:

enter image description here

This tells us a few things about the application: it's using SQLite, the app is in c:\jobs\token\, there's a table data and a few other things.

There is no user data here. It doesn't reveal another person's account balance, private messages, anything like that. While it's possible an error message could reveal that, in practice that is rare.

So how confidential are the application details? The main concern here is making life easier for an attacker. Certain vulnerabilities, such as path traversal and SQL injection are easier to exploit with a bit of information leakage in the error messages. However, they are still exploitable without the information leak - it's just harder work. Restricting error messages does not stop these attacks. It only makes exploitation slightly harder. The change is so minor I don't even consider it when I'm assessing the risk of a vulnerability like SQL injection.

So, the answer to your question is yes, it is safe. It's not best practice, but in no way is it particularly unsafe.

  • Knowing which SQL command is the one giving an error lets an attacker craft a specific injection script, whereas not revealing anything makes the attacker run blind attacks, most likely dropping the target if it's not worth the effort. So, no, it is not safe to show these errors. Commented Sep 30, 2016 at 16:12
  • 1
    @ArturoTorresSánchez - Your idea that an attacker will stop targeting you because there's no error message is unfounded. With tools like sqlmap it's not difficult to exploit
    – paj28
    Commented Sep 30, 2016 at 16:15
  • Why is it unfounded? Script kiddies would be such an example. They attack just for the sake of it, but if they find nothing at a first glance, they'll move to another target. Commented Sep 30, 2016 at 16:19
  • 2
    @ArturoTorresSánchez - Such script kiddies tend to use tools, like sqlmap, and sqlmap can find blind SQL injection just fine. You may have a point that there is some non-zero class of attacker that would be deterred. But who cares? We've still got to defend against the other 99% of threats, where the error messages make no difference.
    – paj28
    Commented Sep 30, 2016 at 16:25

Giving out details of your database setup is generally a bad idea. Legitimate users should not need to know about it and malicious users may find something there that they'd otherwise have to make guesses at.

Other answers have rather well detailed what kind of risk this may pose to your database.

Showing the error report may also open a whole new attack vector in your website. Say, what if I requested the document with ID <script>alert('XSS')</script> — likely that one is not found in the database and I get the error report. Error handlers often are not the most carefully built part of a codebase, so I may just have managed to execute an XSS attack against the site.

  • This is actually a very good answer (+1). To prevent XSS, now you not only need to look after user data being directly shown, but also after user data regurgitated from MySQL errors. New attack vector to look after right there.
    – grochmal
    Commented Sep 30, 2016 at 15:44

Syntax error messages for SQL statements should never be revealed, as that would really save time for the attacker trying to exploit an SQLi vulnerability.

Application line numbers are less severe, but from a security perspective, the error page should not reveal any details, because error pages are often an intermediate step used to complete a successful hack.

If you wish to keep the convenience of detailed error pages, I would recommend configuring your system to only reveal such details to authorized persons based on LAN IP address, and perhaps also some Cookie-based authentication. If code your own custom error pages, this should be reasonably straight-forward to do.

Otherwise, you'll just have to use the less convenient approach of looking in the error logs whenever you need such details.


It’s highly recommended not to show the actual error to users. This applies everywhere, not only in MySQL. You should use a try catch block to handle errors.

In your case, a user or attacker might see your table name, row details, and name. A hacker may use SQL injection or any other attack through your provided error. So it’s better to hide these sensitive details.


It is definitely not a good idea to show details of your database environment to users. The backend of your system should be a total mystery to users. Your server logs should give you enough information to diagnose errors such as the one you have shown.

You should also consider what users can see if they view the source of any page of your web application — does the page source reveal database table or column details in form field names?

If you have time, you could mess with attackers by having fake error messages displayed, which describe database objects that do not exist in your database. Then attackers would be frustrated trying to attack those tables.

You must log in to answer this question.

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