Logs are how you detect and investigate attacks, and errors are how attackers learn about your system; both need deliberate design.
- Document what is logged, in a consistent, machine-readable format with timestamps and context.
- Log security events such as authentication, authorization failures and attempts to bypass controls.
- Protect logs from injection, tampering and unauthorized access, and keep sensitive data out of them.
- Return generic error messages, keep a last-resort error handler, and fail securely.
Each requirement has a level. Level 1 holds the first-layer defenses (about a fifth of the standard), Level 2 adds what OWASP says most applications should strive for, and Level 3 adds defense-in-depth and harder-to-implement controls; meeting a level means meeting every requirement of the levels below it too. Cite a requirement with the version, for example v5.0.0-16.1.1.
V16.1 Security Logging Documentation · 1 requirement
V16.1.1 Level 2
Verify that an inventory exists documenting the logging performed at each layer of the application's technology stack, what events are being logged, log formats, where that logging is stored, how it is used, how access to it is controlled, and for how long logs are kept.
V16.2 General Logging · 5 requirements
V16.2.1 Level 2
Verify that each log entry includes necessary metadata (such as when, where, who, what) that would allow for a detailed investigation of the timeline when an event happens.
On this site: Create security logs someone can investigate (guide) · Case study: the Okta support-system breach and session tokens in HAR files (2023) (guide)
V16.2.2 Level 2
Verify that time sources for all logging components are synchronized, and that timestamps in security event metadata use UTC or include an explicit time zone offset. UTC is recommended to ensure consistency across distributed systems and to prevent confusion during daylight saving time transitions.
V16.2.3 Level 2
Verify that the application only stores or broadcasts logs to the files and services that are documented in the log inventory.
V16.2.4 Level 2
Verify that logs can be read and correlated by the log processor that is in use, preferably by using a common logging format.
V16.2.5 Level 2
Verify that when logging sensitive data, the application enforces logging based on the data's protection level. For example, it may not be allowed to log certain data, such as credentials or payment details. Other data, such as session tokens, may only be logged by being hashed or masked, either in full or partially.
On this site: Create security logs someone can investigate (guide) · Hard-coded secrets (fix card)
V16.3 Security Events · 4 requirements
V16.3.1 Level 2
Verify that all authentication operations are logged, including successful and unsuccessful attempts. Additional metadata, such as the type of authentication or factors used, should also be collected.
V16.3.2 Level 2
Verify that failed authorization attempts are logged. For L3, this must include logging all authorization decisions, including logging when sensitive data is accessed (without logging the sensitive data itself).
On this site: Create security logs someone can investigate (guide) · Case study: Storm-0558 and the forged Microsoft tokens (2023) (guide)
V16.3.3 Level 2
Verify that the application logs the security events that are defined in the documentation and also logs attempts to bypass the security controls, such as input validation, business logic, and anti-automation.
V16.3.4 Level 2
Verify that the application logs unexpected errors and security control failures such as backend TLS failures.
V16.4 Log Protection · 3 requirements
For the whole section: Prevent CRLF header injection, log forging and CSV formula injection (guide) · Apply a security baseline across AWS, Azure and Google Cloud (guide)
V16.4.1 Level 2
Verify that all logging components appropriately encode data to prevent log injection.
On this site: Create security logs someone can investigate (guide) · CRLF injection in logs and response headers (fix card)
V16.4.2 Level 2
Verify that logs are protected from unauthorized access and cannot be modified.
V16.4.3 Level 2
Verify that logs are securely transmitted to a logically separate system for analysis, detection, alerting, and escalation. The aim is to ensure that if the application is breached, the logs are not compromised.
On this site: Create security logs someone can investigate (guide) · Contain cascading failures and rogue agents (guide)
V16.5 Error Handling · 4 requirements
V16.5.1 Level 2
Verify that a generic message is returned to the consumer when an unexpected or security-sensitive error occurs, ensuring no exposure of sensitive internal system data such as stack traces, queries, secret keys, and tokens.
On this site: Handle failures without leaking internals or weakening controls (guide) · Ship without debug modes, verbose errors or exposed files (guide) · Hard-coded secrets (fix card)
V16.5.2 Level 2
Verify that the application continues to operate securely when external resource access fails, for example, by using patterns such as circuit breakers or graceful degradation.
On this site: Bound background jobs and make retries safe (guide) · Contain cascading failures and rogue agents (guide)
V16.5.3 Level 2
Verify that the application fails gracefully and securely, including when an exception occurs, preventing fail-open conditions such as processing a transaction despite errors resulting from validation logic.
On this site: Handle failures without leaking internals or weakening controls (guide)
V16.5.4 Level 3
Verify that a "last resort" error handler is defined which will catch all unhandled exceptions. This is both to avoid losing error details that must go to log files and to ensure that an error does not take down the entire application process, leading to a loss of availability.
Requirement IDs, levels and text are from the OWASP Application Security Verification Standard 5.0.0 (copyright © 2008-2025 The OWASP Foundation), unmodified, under the Creative Commons Attribution-ShareAlike 4.0 International License. Imported from release v5.0.0_release (commit 5cf9b03); license.
Guides on this site
Create security logs someone can investigate
Record meaningful decisions with consistent structure, protect the resulting evidence, and prove that important events reach an operational owner.
Handle failures without leaking internals or weakening controls
Give callers a useful, bounded response while preserving protected diagnostic evidence and safe application state.
Turn runtime events into a tested investigation and containment path
Collect evidence that answers a concrete security question and rehearse the response without destroying the facts needed to investigate.
References
- V16 Security Logging and Error Handling (ASVS 5.0.0 source)
- OWASP Web Security Testing Guide: Testing for Error Handling
- OWASP Authentication Cheat Sheet section about error messages
- OWASP Logging Cheat Sheet
- OWASP Application Logging Vocabulary Cheat Sheet
List data from the publisher. A guide is listed as the main subject when the weakness or risk is what the guide is about, and as covering it when a dedicated section or worked example addresses it.