Error logging forms a critical part of the software development lifecycle, aiding debugging and early detection of failures. However, logs must remain both informative and secure to avoid unintended information disclosure.
The article, written by Natalia Noyanova of T1 IT Holding, draws on years of experience in information security and static code analysis. It highlights how code analyzers flag internal or external information leaks tied to error logging and explains why fixing these issues requires more than simple code changes.
Logging levels range from DEBUG (detailed diagnostic data not used in production) through INFO, WARNING, ERROR to FATAL (critical errors that halt the application). Recording mechanisms include plain text files, multi-stage logs requiring special readers, binary formats and databases.
Trace ID provides a unique technical identifier generated at the API gateway for each incoming request and propagated unchanged through all microservices. Correlation ID links multiple technical requests that belong to one business transaction, such as an order placement involving inventory, payment and confirmation steps.
Examples of exploitation include Flask applications running with debug=True that return full stack traces revealing absolute paths like /app/main.py and Python interpreter versions. Similar leaks occur when developers manually return traceback.format_exc() or forward raw SQLite errors after failed queries, confirming the database engine and aiding SQL injection refinement.
Prevention measures cover removal of X-Powered-By and Server headers via Nginx server_tokens off, input sanitization with regular expressions to block newlines in trace identifiers, and adoption of OpenTelemetry for automatic generation of safe hex-formatted trace IDs. Structured JSON logging further isolates fields and prevents log injection attacks described under CWE-117.


