No Logging at All
- Exception Handler without any code are an obvious example of this, but reading a configuration file without giving a hint which whan you are reading and what you found in it also belongs in this category
- Wrong Log Level
- logging the discovery that you can’t connect to the database of the application in DEBUG level, or logging entry and exit points of method with ERROR level are typical examples. Always remember: Once in production the log level will probably risen to WARN or ERROR and you gonna still want to see the important messages, don’t you?
- Catch Log Throw
- In a catch block the exception gets logged and then thrown again, possibly wrapped in a new exception. When this anti pattern is used in many places the result is a log file that contains every stacktrace in a dozen repetitions and variations. A nightmare when you try to understand what is going on.
- Logging to stderr or stdout
- System.out.println and ex.printStacktrace() are easy and fast to write, but their result will probably disappear in /dev/null once your application is running on a production server.
- Complex Logging Statements
- When the message for logging gets constructed in a convoluted way with lots of function calls, there is a serious risk that you end up with a NullPointerException instead of a proper logging entry. This is especially true when we try to log inside a catch block. After all something went wrong in the first place, so NULL values a everywhere
Best practices for all organizations that would like to produce more secure applications!
As part of the software development process, security professionals must make choices about where to invest their budget and staff resources to ensure that homegrown applications are as secure as possible. ESG research found organizations that are considered security leaders tend to make different choices than other firms.