I've got a bug... the application that I've deployed isn't working in this configuration. It's not even hitting my controller for me to be able to log to a file.
So, I kick the log level from warn to debug and I see that Spring is booting it because it failed a CORS check. This was much easier than trying to reproduce it in my local system and attach a debugger to it.
There is a lot that goes on beneath and behind the code that a person writes within the libraries. I would contend that the log4j vulnerability is because people didn't realize the extent of what was going on beneath and behind.
Making a developer blind to what goes on inside a library is not the answer. The "what goes on inside of a library" is indeed a concern for the application and the developer and should be made as easy to access as possible.
Is this partly due to the fact that everyone is depending on the libraries having logs instead of throwing the correct exception? Then the application could log it.
A program working correctly with incorrect input isn't an exceptional case.
"This endpoint cannot be accessed in a CORS improper way" is caught in the library/framework level and doesn't even touch my code - there's no exception for me to catch.
Throwing a checked exception for no access rather than returning "false" from a library call because you passed in all upper case on case sensitive role check would be a decision that I wouldn't agree with.
Another example would be "I want to see the sql generated by hibernate" - that's not exception throwing at all, its me trying to debug what the query is and why the performance is awful.
So, I kick the log level from warn to debug and I see that Spring is booting it because it failed a CORS check. This was much easier than trying to reproduce it in my local system and attach a debugger to it.
There is a lot that goes on beneath and behind the code that a person writes within the libraries. I would contend that the log4j vulnerability is because people didn't realize the extent of what was going on beneath and behind.
Making a developer blind to what goes on inside a library is not the answer. The "what goes on inside of a library" is indeed a concern for the application and the developer and should be made as easy to access as possible.