Secure Error Logging Practices to Prevent Information Leaks Across Java, Kotlin, JavaScript and Python

The article examines how improper error logging can expose sensitive details such as stack traces, file paths, library versions and database structures, enabling attackers to map applications and craft targeted exploits. It covers core logging levels from DEBUG to FATAL, mechanisms including text files, binary logs and databases, plus the roles of Trace ID and Correlation ID in tracing requests across microservices. Real-world vulnerable code examples in Flask and SQLite demonstrate direct exception output, manual traceback exposure and SQL error leakage that confirm technologies like Python 3.10 or SQLite usage. CWE categories including CWE-209, CWE-532, CWE-538 and CWE-1295 are referenced to classify risks of information disclosure through logs. Mitigation steps include stripping version headers in Nginx, sanitizing inputs with regular expressions, using OpenTelemetry for structured JSON logging and avoiding debug modes in production. The guidance stresses balancing detailed logs for incident response with protections against injection and reconnaissance.

HabrTranslated from Russian

Read at source

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.

Meridian digestThe week's most consequential security stories, distilled into one briefing.See the digest

More in Vulnerabilities & Exploits

Telegram for Android Patches Voice Call Vulnerability Enabling Code Execution
Yandex Patches Millions of Stations After eMudhra Certificate Keys Compromised
Cisco ASA and FTD Face DoS Vulnerability in SSL VPN Already Exploited in the Wild