+V16 Security Logging and Error Handling
---+V16.1 Security Logging Documentation
------+V16.1.1 Verify that an inventory exists documenting the logging performed at each layer of the …
---+V16.2 General Logging
------+V16.2.1 Verify that each log entry includes necessary metadata (such as when, where, who, what) that would …
------+V16.2.2 Verify that time sources for all logging components are synchronized, and that timestamps in …
------+V16.2.3 Verify that the application only stores or broadcasts logs to the files and services that are …
------+V16.2.4 Verify that logs can be read and correlated by the log processor that is in use, preferably by …
------+V16.2.5 Verify that when logging sensitive data, the application enforces logging based on the data's …
---+V16.3 Security Events
------+V16.3.1 Verify that all authentication operations are logged, including successful and unsuccessful …
------+V16.3.2 Verify that failed authorization attempts are logged. For L3, this must include logging all …
------+V16.3.3 Verify that the application logs the security events that are defined in the documentation and also …
------+V16.3.4 Verify that the application logs unexpected errors and security control failures such as backend …
---+V16.4 Log Protection
------+V16.4.1 Verify that all logging components appropriately encode data to prevent log injection.
------+V16.4.2 Verify that logs are protected from unauthorized access and cannot be modified.
------+V16.4.3 Verify that logs are securely transmitted to a logically separate system for analysis, detection …
---+V16.5 Error Handling
------+V16.5.1 Verify that a generic message is returned to the consumer when an unexpected or security-sensitive …
------+V16.5.2 Verify that the application continues to operate securely when external resource access fails, for …
------+V16.5.3 Verify that the application fails gracefully and securely, including when an exception occurs …
------+V16.5.4 Verify that a "last resort" error handler is defined which will catch all unhandled exceptions. …

V16 Security Logging and Error Handling

Control Objective

Security logs are distinct from error or performance logs and are used to record security-relevant events such as authentication decisions, access control decisions, and attempts to bypass security controls, such as input validation or business logic validation. Their purpose is to support detection, response, and investigation by providing high-signal, structured data for analysis tools like SIEMs.

Logs should not include sensitive personal data unless legally required, and any logged data must be protected as a high-value asset. Logging must not compromise privacy or system security. Applications must also fail securely, avoiding unnecessary disclosure or disruption.

For detailed implementation guidance, refer to the OWASP Cheat Sheets in the references section.

References

For more information, see also:

1. Översikt

V16.1 Security Logging Documentation

This section ensures a clear and complete inventory of logging across the application stack. This is essential for effective security monitoring, incident response, and compliance.
V16.2 General Logging

This section provides requirements to ensure that security logs are consistently structured and contain the expected metadata. The goal is to make logs machine-readable and analyzable across distributed systems and tools.

Naturally, security events often involve sensitive data. If such data is logged without consideration, the logs themselves become classified and therefore subject to encryption requirements, stricter retention policies, and potential disclosure during audits.

Therefore, it is critical to log only what is necessary and to treat log data with the same care as other sensitive assets.

The requirements below establish foundational requirements for logging metadata, synchronization, format, and control.
V16.3 Security Events

This section defines requirements for logging security-relevant events within the application. Capturing these events is critical for detecting suspicious behavior, supporting investigations, and fulfilling compliance obligations.

This section outlines the types of events that should be logged but does not attempt to provide exhaustive detail. Each application has unique risk factors and operational context.

Note that while ASVS includes logging of security events in scope, alerting and correlation (e.g., SIEM rules or monitoring infrastructure) are considered out of scope and are handled by operational and monitoring systems.
V16.4 Log Protection

Logs are valuable forensic artifacts and must be protected. If logs can be easily modified or deleted, they lose their integrity and become unreliable for incident investigations or legal proceedings. Logs may expose internal application behavior or sensitive metadata, making them an attractive target for attackers.

This section defines requirements to ensure that logs are protected from unauthorized access, tampering, and disclosure, and that they are safely transmitted and stored in secure, isolated systems.
V16.5 Error Handling

This section defines requirements to ensure that applications fail gracefully and securely without disclosing sensitive internal details.

Note: Certain languages, (including Swift, Go, and through common design practice, many functional languages,) do not support exceptions or last-resort event handlers. In this case, architects and developers should use a pattern, language, or framework-friendly way to ensure that applications can securely handle exceptional, unexpected, or security-related events.

1.1 Referenser

1.2 Identifierade krav

1.3 Relaterade regleringar

2. Identifierade krav

Krav

3. Relaterade regleringar

Regleringar
  • OWASP -

    EN: Publications of the OWASP Foundation, https://owasp.org/. OWASP® is a registered trademark of the OWASP Foundation, Inc.; GRCA is not affiliated with, nor endorsed by, the OWASP Foundation. Only the versions published by OWASP are authoritative.

    DE: Veröffentlichungen der OWASP Foundation, https://owasp.org/. OWASP® ist eine eingetragene Marke der OWASP Foundation, Inc.; GRCA steht in keiner Verbindung zur OWASP Foundation und wird von ihr nicht unterstützt. Maßgeblich sind allein die von OWASP veröffentlichten Fassungen.