Secure by default: default should only show errors to admin users

You are running a development version of Drupal as depicted on the screenshot, which shows all error messages, since it is focused on developers. Drupal releases does not show the NOTICE level errors you shown on the screenshot. Also, I don't get how you assume this error reveals names of enabled modules (I see only one enabled module exposed in the error message).

Higher then notice level errors still show up by default in Drupal. You can disable showing errors to ALL users on the error settings administration page (including hiding them from administrators), so that errors will only be stored in logs. Showing errors depending on the user role of the logged in user is a feature not present in Drupal 6 and to be suggested for Drupal 7, where new features go. Moving there and retitling appropriately based on your suggestion.

Since the TinyMCE module exposes a certain identifiable user interface, and it adds images, CSS and JavaScript to the page (all telling the exact path to the module under your Drupal installation), it would be easy to find out that you run this module. The CSS and Javascript paths included on pages, paths of your features and so on tells much more about the modules you use.

As said, I agree it would be a nice new feature to only show errors to admins.

Attached is a proposed patch. I simply created a new permission and checked whether the current user has access to view the messages of the 'error' type. I opted to check this in theme_status_messages() and not in drupal_get_messages() since I'm not quite sure how many features might be available in bootstrap.inc. (e.g.: during installation,...)

I shall attempt to fix these when I get home and take a more in depth look at it.

After a small investigation it seems that the unit tests are failing because the new permission was not enabled, the error messages were not shown and the assert failed because it was expecting an error message. One example is the comment test which simulates the behavior that anonymous users can post comments. If an administrator allows that he will be forced to allow the anonymous user to view all the error messages because otherwise the anonymous user will not be notified if he made an error filling something in.

I changed the status to active (needs more info) to allow a bigger discussion and to include the possibility I misinterpreted the original report if it wasn't about regular error messages but only low-level (PHP, MySQL, ...) related error messages.

The problem with globally hiding all "error" messages is that many of these messages provide valuable information to the user, such as forgetting a required field, or an incorrect login. In order to solve this issue, one would have to implement a new type of drupal_set_message to account for the differences in types of errors. At this time, we have "status", "warning", and "error"... maybe the correct implementation is to create a new type of "system error" and output all mysql and php errors through this new type. That way, we could allow users to see "error" messages such as missing a required field, but restrict them from seeing these potentially user-unfriendly system errors.

I'd opt for the approach described by @ultimateboy. System errors and user errors are fundamentally different and a non-admin user has no need to see the details of a system error.

There ought to be an option that allows an admin to control if a system error is completely ignored, tells the user that an error has occurred but gives no details, or gives all details of the error (a site in development mode).

This cannot be fixed by Drupal. PHP notices always contain the full path to the PHP file that triggered a notice/warning/error.

I would add that this is a bad idea anyway: (1) Drupal has a setting to hide PHP errors completely... this is the setting you want to use in production, (2) during development, you want to see all errors, including those affecting anonymous users.

You don't want to hide notices/warnings/errors by default. If you hide them, mysterious things happen on your site and you have no clue why something does not work. You cannot provide solid bug reports if you encounter a "misbehavior", because you do not even know there happened an error somewhere.

As I said already, Drupal has a setting to hide PHP errors completely... this is the setting you want to use in production. During development, you want to see all the errors everywhere (and fix them before launching the website...).

@Aren Cambre

Definitely agree, updated a poorly written module and suddenly all of my sites (perhaps a dozen) were showing errors to anonymous users!!! Not only is this insecure, it's a colossal embarassment to those of us who are trying to run a business. "Hey, anonymous user, get ahold of the site owner and let them know to get ahold of their sys admin that table x for mod y is missing. Now my customers think I have no idea what I'm doing, when really it's the developers of my CMS... ok ok ok it's both =cp ) Sorry to whine, but surely someone somewhere thought this through. DO NOT SHOW ERRORS TO ANONYMOUS USERS EVER. Oops, caps lock broken, my bad.

@Damien

That's great in theory but exactly zero drupal users know this until they learn the hard way. Who would have thought Drupal would serve errors to anonymous users? Wow just wow.

"Postponed" doesn't seem like the right status here because there is nothing specific it's postponed on. It should be set to needs work (possibly for Drupal 7, or possibly for Drupal 8 at this point).

As far as I can tell, the original goal of this issue could be met by adding a setting at admin/config/development/logging which is basically "Who should see PHP error messages? (a) All users (b) Only users with the XYZ permission". And then check for that permission in the Drupal error handler itself (that way it automatically only applies to PHP error messages rather than those which are intentionally set by module authors).

That sounds to me like it it's doable. Whether it's a good idea or not is another question...

sub

And so? The issue is still needing work but it seems nobody is actually working on it..
I think the way suggested by Damien in comment #12 is the better way to get trough this but the issue status is very ambiguous.. shouldn't we change it?

@Aren if you don't enable js and css consolidation you have a list of css and js links in your page header, one (or more) for each module that needs an inclusion. So js and css consolidation is also an actual security enhancement (simple, very simple, but effective) to make hard to find the list of active modules. But I'm still confused about how would you completely hide all these informations.. I think you can just make them hard to find, but not really hide them...

Since nobody is interested in this issue and drupal seems to work as designed i'm setting as closed

Related feature request: #2743119: Option to display php error messages in a block so we can limit visibility per role

Isn't it what Status Messages Block does? Which leads to #3247587: Status messages block visibility does not behave as expected.