The application was found to return database error messages. Determining the type of database may assist attackers in exploiting SQL Injection attacks against the system. While debug messages are helpful during development and debugging, they should not be presented to users when an error occurs.
Applications should handle database error conditions internally and map known failure types to error codes that can be displayed to a user. These error codes should be customized to the application and returned along with the relevant HTTP error code.
When an error occurs, the application identifies the error type or class, and displays a numerical value to the user. Requests should also be tracked so when a user is presented with an error code, it has a corresponding request ID. Support teams can then correlate the HTTP error, the customized error code, and the request ID in the log files to determine the root cause of the error without leaking details to the end user.
Example of returning customized errors:
HTTP/1.1 500 Internal Server Error ... Error  Occurred, please contact support or re-try your request again shortly. Request ID [a4bc91def12] ...