OWASP Secure Logging Benchmark
Introduction
Application logs often contain sensitive information, or expose details such as internal endpoints that give an attacker easy targets. The OWASP Top 10 (2021) recognises this risk under A02 Cryptographic Failures (formerly Sensitive Data Exposure) and A09 Security Logging and Monitoring Failures. Logging is valuable, but it is a double-edged sword.
Developers usually design logs for debugging, and for other developers. A secure logging standard treats logs as security and forensic artefacts as well. Detecting and responding to an incident depends heavily on the information that was built into the application logs before the incident occurred.
Two failure modes are common. In the first, logging is so verbose that critical events are lost in the noise, or are overwritten before anyone reads them. In the second, events are logged with little or no context, so they cannot be interpreted. Logs should therefore be designed not only for developers, but also for the forensic analyst who will one day need to reconstruct what happened.
Messy, noisy logs are often a symptom of unclean code: log levels are not set correctly, data is tagged inappropriately, and sensitive values leak into production logs. Deliberate log design, with controls built in to prevent sensitive data disclosure, avoids these problems.
Project Overview
The project provides a benchmark for application logs based on NIST SP 800-53 security controls, in particular the Audit and Accountability (AU) family, while taking debugging needs and system performance into account. It covers:
- Log levels and what they mean
- Event categories and why they matter
- Data classification and prevention of sensitive data disclosure
- Log structure
- Log message content and how to identify weaknesses in it
- Building forensic readiness into application logs
- Log hygiene and analysis techniques
- Two weeks of training material for populating logging hygiene backlog items to address within sprints
- A guide to applying the benchmark within an application security team
The survey research behind the benchmark is summarised in the Survey Results tab, and common logging weaknesses are described in the Vulnerabilities tab.
Why It Matters
This project is a movement as much as it is a standard. Logs are for more than debugging and system metrics. They give insight into code quality and can reveal problems within development teams. They are essential for understanding a breach, mitigating future breaches, and gathering information for threat modelling.
Update 04 March 2020
This project is in research phase, in which information is gathered about logging best practises in terms of development, security and forensic readiness. The benchmarking scoring metric has been developed and needs to be translated into both a mobile application and web application.
Update 19 December 2023
Updates are being made to the content of the project. This includes the benchmark, a survey and more guidelines around logging.
The Five Philosophies of Log Design
TL;DR: Effective logs should be simple, structured, and informative without compromising sensitive information. Avoid accidental data exposure to prevent security breaches.
Simplicity, Structure, and Detail
A well-designed log should offer a clear understanding at a glance. Avoid over-complication; logs aren’t just data caches but sources of necessary information. Focus on these aspects:
- Log simplicity and structure: Ensure uniformity across logs, regardless of the developer.
- Purpose of logs: Define whether they’re for debugging, security events, or performance metrics. Decide this early to avoid logging irrelevant data.
- Integration with systems like SIEM: Consider how logs will be structured for external analysis.
Tagging and Metadata
Be mindful of the data your application handles. Sensitive information like personal health data (PHI) and personally identifiable information (PII) should be treated cautiously. Consider tagging data to manage privacy levels effectively. Example snippets:
// Non-sensitive data
Logger().info("Smoothie name: \(smoothieName, privacy: .public)")
// Sensitive data
let userPassw : Str = getUserPassw()
Logger().info("User’s Password: \(userPassw, privacy: .secret)")
Clean and Focused Logging
Logs grow with your application. Regular maintenance and cleaning of logs are essential to avoid ‘logging debt’. Aim for logs that are informative and relevant. Regular benchmarking and testing of logs should be a part of your development cycle.
Log with Security in Mind
Assume that a security compromise can occur. Design your logs to assist in forensic analysis and incident response. Logging should cater not only to debugging but also to security and forensic readiness.
Access, Storage, and Transportation of Logs
Be cautious about who can access logs and how they are stored and transmitted. Logs should be informative yet secure, without exposing sensitive application details or user information.
Acknowledgements and Inspiration
A heartfelt thank you to Eric and all the dedicated developers and visionaries who contributed their insights and expertise to this project. Their collective wisdom has been invaluable in shaping these philosophies.
This work is also inspired by the insightful narratives found in ‘The Unicorn Project’ and ‘The Phoenix Project’, which offer profound lessons in IT, DevOps, and software development.
Stay tuned for more in-depth discussions and explorations of these topics. This article was first published on my website and is part of a series dedicated to advancing understanding and best practices in the field of log design.
Survey Results: Logging Culture in Software Development
The survey on logging culture in software development is now closed. It ran from 12 December 2023 to 31 December 2024 as part of doctoral research at the University of Plymouth, and 146 participants completed it. Thank you to everyone who took part and shared it with colleagues.
Developers working on software and firmware were recruited through OWASP and Health-ISAC. They answered questions on logging priorities, training, standards, retention, and the vulnerabilities they have encountered. Their responses were compared against the OWASP Top 10 (2021) dataset and logging-related CWEs, and the findings form the basis of this benchmark.
Key findings
| Finding | Respondents |
|---|---|
| Received no training in privacy or security logging | 64% |
| Work without documented logging guidelines | 60% |
| Struggled to investigate incidents because logs were missing or incomplete | 45% |
| Found passwords, tokens, API keys or PII in log files | 33%+ |
What developers prioritise when designing logs
Readability for developers dominates. Just over half of respondents cite protection of sensitive information, and fewer than four in ten cite regulatory compliance.
Training in secure and privacy-compliant logging
Most developers learn logging through ad hoc guidance or personal experience. Only a quarter have been trained in both the privacy and the security aspects of logging.
Logging vulnerabilities developers have encountered
Over 40% of respondents report each of insufficient logging, sensitive data in logs, and information disclosure. These correspond to CWE-778, CWE-532 and CWE-200.
Findings mapped to known weaknesses
| Finding | Weakness | Consequence |
|---|---|---|
| Security-critical events such as failed logins and privilege changes are not recorded | CWE-778 Insufficient Logging; OWASP A09:2021 | Incidents cannot be detected or reconstructed |
| Credentials, tokens, API keys and PII written to logs | CWE-532 Insertion of Sensitive Information into Log File | Logs become a target and a regulatory liability |
| Excessive or unnecessary detail logged | CWE-200 Exposure of Sensitive Information | Unintended disclosure to anyone with log access |
| Unvalidated input written to log entries | CWE-117 Improper Output Neutralization for Logs | Forged or misleading entries obscure the forensic trail |
| Security context omitted from entries | CWE-223 Omission of Security-relevant Information | Events cannot be attributed or correlated |
Who responded
Design requirements for forensic-ready logging
The survey findings lead to six design input requirements, which form the basis of the benchmark.
- The system shall generate logs in a structured and consistent format to enable reliable parsing, correlation and long-term forensic usability.
- The system shall record security-relevant events, including authentication attempts, access to sensitive data, privilege changes and system configuration modifications.
- The system shall enrich each log entry with contextual metadata.
- The system shall exclude sensitive data from the logs.
- The system shall, where feasible, synchronise all timestamps using a trusted time source such as NTP. Where this is not possible, event sequencing shall be preserved through relative timestamps or monotonic counters.
- The system shall cryptographically bind each log entry to its contents and its predecessor, for example through hashing or chained signatures, so that individual entries are tamper-evident.
Citation
Schmitt, V., Clarke, N., Ghita, B. and Van Niekerk, J. A Structured Approach to Log Design: Addressing Security and Compliance Gaps in Software Development. University of Plymouth and Noroff University College.
Logging Vulnerabilities
Overview
Note: Weaknesses in how applications write, store and monitor logs expose them to security, privacy and compliance risks. This page describes the most common logging vulnerabilities, maps each to its Common Weakness Enumeration (CWE) entry, and gives practical mitigations. The figures quoted come from the Secure Logging Benchmark developer survey, in which respondents reported the vulnerabilities they had encountered (n = 102, multiple selections allowed).
Common Logging Vulnerabilities
1. Insufficient Logging
Warning: Security-relevant events such as failed logins, privilege changes and access to sensitive data are not recorded, or are recorded without the context needed to investigate them. This was the most frequently encountered vulnerability in the survey (46.1%).
- Weakness: CWE-778 Insufficient Logging; CWE-223 Omission of Security-relevant Information; OWASP A09:2021
- Mitigation: Define the security events every component must log. Include a timestamp, user or service identifier, source address, action, target resource and outcome in each entry.
2. Logging Sensitive Information
Important: Passwords, session tokens, API keys, personal data (PII) or health data (PHI) are written to logs. 44.1% of respondents had encountered sensitive information in logs, and 35.3% had found authentication information.
- Weakness: CWE-532 Insertion of Sensitive Information into Log File
- Mitigation: Classify data before logging it. Apply allow-list logging or masking filters in the logging framework, never log authentication material, and scan existing logs for leaked secrets.
3. Information Disclosure Through Logs
Important: Logs record more detail than diagnostics require, such as full stack traces, internal hostnames, endpoints or query strings, and are exposed to users or attackers. 43.1% of respondents had encountered this.
- Weakness: CWE-200 Exposure of Sensitive Information to an Unauthorized Actor
- Mitigation: Log only what is necessary for diagnostics and auditing. Return generic error messages to users and keep detailed diagnostics in protected logs.
4. Log Injection and Poisoning
Warning: Unvalidated input written to a log allows an attacker to forge entries, break log parsing or inject content that misleads analysts. 11.8% of respondents had encountered log poisoning.
- Weakness: CWE-117 Improper Output Neutralization for Logs
- Mitigation: Encode or strip control characters such as CR and LF from user-supplied values. Use structured formats such as JSON, so that input is stored as a field value and never interpreted as log syntax.
5. Log Flooding and Suppression
Warning: An attacker generates excessive log volume to exhaust storage, push older entries out of rotation or hide activity in noise, or blocks logging entirely. 16.7% of respondents had encountered blocking or overloading of logging systems.
- Weakness: CWE-779 Logging of Excessive Data; CWE-400 Uncontrolled Resource Consumption
- Mitigation: Use appropriate log levels in production, rate-limit repetitive events, size storage for peak volume, and alert when log sources go silent.
6. Tampering and Insecure Storage
Important: Logs stored without access controls or integrity protection can be read, altered or deleted, which destroys their value as evidence.
- Weakness: CWE-117 (forged entries); CWE-532 (exposure of stored logs)
- Mitigation: Restrict access to authorised personnel, encrypt logs in transit and at rest, forward them to a central store, and make entries tamper-evident through hash chaining or signatures.
7. Inconsistent Timestamps and Formats
Warning: Unsynchronised clocks and inconsistent formats between systems make it impossible to reconstruct an accurate event timeline across components.
- Mitigation: Synchronise clocks with a trusted time source such as NTP and record timestamps in UTC using ISO 8601. Where synchronisation is not possible, preserve ordering with monotonic counters. Adopt one structured log format across teams.
8. Failure to Monitor and Retain Logs
Warning: Logs that are never reviewed, or are purged before an incident is discovered, provide no detection capability and no evidence.
- Mitigation: Feed logs into monitoring and alerting such as a SIEM, and set retention periods that match detection timelines and regulatory obligations.
Best Practices for Secure Logging
Tip: These practices address the vulnerabilities above and align with the benchmark’s forensic-ready logging requirements.
- Structured format: Use a consistent, machine-readable format across all teams and systems.
- Security events: Record authentication attempts, access to sensitive data, privilege changes and configuration changes.
- Context: Enrich every entry with the metadata needed to attribute and correlate it.
- Minimise data exposure: Exclude or mask sensitive data, and log only what is necessary.
- Trusted time: Synchronise timestamps, or preserve event order where synchronisation is not possible.
- Integrity: Make log entries tamper-evident and restrict access to authorised personnel.
- Monitoring and retention: Alert on suspicious activity and retain logs long enough to support investigation.
- Regular audits: Review logging configuration and log content as part of each release.