> In an ideal world they are never revealed to the end user, but real-world solutions fall short. It's not uncommon for people to have display_errors enabled for some reason or another. It is also possible for sites to be misconfigured, or for applications to make mistakes and accidentally dump stack traces without realising that they may contain arguments. Not all applications make use of an error handling framework, and people may enable display_errors without understanding the ramifications.
Developers and system administrators are able to mess up their INI settings in whatever way they want. We can't prevent that. It's a much bigger issue if someone has display_errors set to On in production environment, and they could also have set the exception_ignore_args to Off. We can only suggest the default values for the production environment. In such a case, I'd argue that setting exception_ignore_args to Off while having display_errors=Off isn't a big problem. The exception is already sensitive information, maybe not on the level of PII, but it's definitely something that needs to be securely protected from end users. >Can you elaborate? Setting it Off by default increases the risk of accidental information leakage when apps aren’t correctly configured. That's great for developers, but for production sites that's not a good idea. There is no way to guarantee that every PHP application is a perfect, well-configured, system which uses the latest frameworks. Many of us are dealing with massive legacy codebases. Accidental leakage isn't a good argument for keeping this setting On in production. There should be no accidental leakage, and to prevent that PHP recommends setting display_errors to Off in the production environment. It is possible that some application messed up so badly that even with display_errors=Off they might still expose stack trace to the user, but that's a security bug that should already be reported to the application developers regardless of whether the stack trace contains arguments or not. In my opinion, the only valid argument here is whether it's ok for arguments to be present in the log files. This would only occur due to an Exception, Error or Warning/Notice being triggered by the code. Error log files are supposed to be checked regularly, and errors should be fixed. Thus, it's only in exceptional situations that this would happen, i.e. yet an undiscovered bug. Log files should be treated with similar care as the database, with only the administrators having controlled access. This means that the only information that should not appear in log files is the same information one wouldn't expect to find in the database, e.g. passwords. We have a solution for this now, it's #[SensitiveParameter]. You do bring up a good point that many applications still do not use it due to wanting to support older PHP versions, but keep in mind that exception_ignore_args is only available as of PHP 7.4, so users of older PHP versions are screwed either way. Those on PHP 7.4 > 8.2 can use this INI setting as a substitute for the new attribute. On the other hand, if an undiscovered bug happens in the production environment, it is very useful to know exactly under what circumstances that happened. Having the full arguments or even just a truncated part in the stack trace in your log files could make finding the bug much easier. So it's probably even more important to have the arguments in the production environment than it is in the development.
