|When you opt to display errors, an error is sent to the standard output stream, which in the case of a Web page means that it is sent to the browser.You toggle this setting on and off via this php.ini setting:|
display_errors = On
display errors is very helpful for development because it enables you to get instant feedback on what went wrong with a script without having to tail a logfile or do anything but simply visit the Web page you are building. Whatâ€™s good for a developer to see, however, is often bad for an end user to see. Displaying PHP errors to an end user is usually undesirable for three reasons:
1.It looks ugly.
2.It conveys a sense that the site is buggy.
3.It can disclose details of the script internals that a user might be able to use for nefarious purposes.
from perusing the code that had appeared on the Web for mere hours the year before. We were lucky in that case:The main exploits he had were on unvalidated user input and nondefaulted variables (this was in the days before register_global
). All our database connection information was held in libraries and not on the pages. Many a site has been seriously violated due to a chain of security holes like these:
1.Leaving display_errors on.
2.Putting database connection details (mysql_connect()) in the pages.
3.Allowing nonlocal connections to MySQL.
These three mistakes together put your database at the mercy of anyone who sees an error page on your site.You would (hopefully) be shocked at how often this occurs. I like to leave display_errors on during development, but I never turn it on in production.