We have to think about this a little bit, because some errors are meant to be shown (like SAML2 errors).
We don't show backtraces by default, so the only thing an attacker would gain is a slightly more descriptive error-message.

Fair enough if there's some nuance and it's desirable sometimes for a meaningful error message to be shown to users.

However in the case of the XXE vulnerability the display of verbose error messages can definitely be abused - happy to share more details if that would help.

Would it make sense to implement something like an additional verboseerrors flag or make showerrors a sliding scale (say from 0 to 3?) instead of a boolean?

The default could then be to show only very minimal error messages / those that would useful to an end user, but retain the ability to increase the verbosity e.g. for debugging during set up.

A possible solution is #2521

In 2521 you can select explicitly which errors to show the description/backtrace for and if the error is not selected it doesn't get the backtrace.

I made the array allow picking explicitly so you can do the following to show no errors. A bit counter productive though since you could just not use the option and set showerrors = false;

'showerrors.whitelist' => [
        'ACSPARAMS' => false,
];

Focusing on 2.4.

I am tinkering with my config.php but it seems that debug traces are shown for me in the browser when using the default values. Sorry if I have something set in config.php that does this but I can't see what that might be when looking over a diff to config.php.dist. I have errorreporting=false in mine.

    'showerrors' => true,
    'errorreporting' => true,
    'production' => true,

In error.twig it is using if showerrors to work out if the message/trace is to be shown. That comes from error.exceptionTrace.

The exceptionTrace is output in src/SimpleSAML/Error/Error.php which comes from $this->format(true); and that ultimately leads to Exception::formatBacktrace which doesn't seem to have any other logic such as that in #2521 to limit which errors will produce a stack trace.

Given that, we have already had the 'backtraces' option for the debug setting. We can respect that setting with the error setting to surface the detailed debug information in the error page if desired.

The proposed changes are:

• The 'showerrors' is disabled by default.
• If no debug flags are configured, no additional information will appear on the error page. Currently, stack traces are always displayed whenever showerrors is enabled, regardless of the debug settings.
• If 'backtraces' is enabled in the debug option, the stack traces information will display along with the error messages.

In a user case where the user does want to have the stack trace details in the logs, but does not want those information expose to the client side (a browser). The configuration should be set as:

'debug' => [
        'backtraces' => true,
    ],
'showerrors' => false,

which aligns with the current behaviour.

Proposed PR: #2540

Since this was the original PR to raise the issue and there seems consensus that setting showerrors to false is a good move for the default config I will merge this.

If showerrors is true in general then there is a potential to leak information to expressly nefarious users.

I will follow up discussion as to if the default is modified in the 2.5 series and/or how this might be communicated to administrators in general who have not changed the default setting.

@mcdruid thank you for the detailed PR.