Home/ Blog/ Logging & Monitoring Failures Testing
June 19, 2026 · 9 min read

Security Logging and Monitoring Failures: How to Find OWASP A09 Gaps

The average time between a breach occurring and an organization detecting it is 194 days. That number — from IBM's Cost of a Data Breach report — is not primarily a detection technology problem. It's a logging problem. You can't alert on events you never recorded.

OWASP A09 (Security Logging and Monitoring Failures) is unlike most of the Top 10. The vulnerability isn't something an attacker directly exploits to gain access. It's the absence of a control that would let you know you've been compromised. SQL injection gives the attacker data. Missing logging gives them time — time to enumerate, escalate, pivot, and exfiltrate before anyone notices.

This makes A09 gaps simultaneously invisible from the outside and catastrophic in their impact. An attacker who knows your logs are weak will move slowly and methodically. An attacker who triggers no alerts has no deadline.

This guide covers how to assess logging and monitoring coverage, test for log injection, identify sensitive data leaking into logs, and understand what automated DAST tools can and cannot tell you about this category.

Common Vulnerability Patterns

A09 manifests across several distinct failure modes. Each requires a different testing approach.

No logging of authentication events Failed login attempts, password reset requests, MFA failures, and account lockout events are not recorded. This is the most impactful single gap — credential stuffing, brute force, and account takeover campaigns generate enormous volumes of failed auth events. Without these logs, there's no signal to alert on and no forensic trail to reconstruct what happened after a successful compromise.
Insufficient log detail Events are logged, but without the fields needed to support investigation: no user ID, no source IP, no timestamp with timezone, no resource identifier, no outcome. A log entry that says login failed with no username or IP is nearly useless for incident response. Logs that don't support forensics are nearly as bad as no logs.
Logs written but not monitored The application generates logs, but nothing reads them. No SIEM integration, no alerting rules, no dashboards. This is extremely common — teams implement logging for compliance checkboxes and never wire it to detection. The log file fills up on a server somewhere while an attacker operates for months.
Log injection vulnerabilities User-controlled input is written directly to logs without sanitization. This enables an attacker to inject newline characters to forge fake log entries, inject ANSI escape codes to corrupt terminal-displayed logs, or craft entries that confuse log parsers and break SIEM ingestion. Log injection doesn't give direct system access, but it lets attackers cover their tracks or plant false evidence.
Sensitive data written to logs Passwords, session tokens, API keys, credit card numbers, or PII are logged in plaintext — often through error handlers that serialize entire request objects. This turns your log storage into a second secret store that's typically far less protected than your primary credential vault.
Missing audit trails for critical actions Admin access, privilege escalation, data exports, bulk deletions, configuration changes, and permission modifications are not logged at all — or logged without sufficient context. These are precisely the actions attackers and malicious insiders take after gaining initial access. Without audit trails, you have no way to determine the scope of what was accessed or modified.

Testing Logging Coverage

The core technique for testing logging coverage is deliberate triggering: perform actions that should generate log entries, then verify those entries exist and contain the right fields.

If you have access to logs (white-box or grey-box testing), this is direct. If you're testing black-box, you're inferring logging behavior from application responses and out-of-band signals.

Authentication event logging

Perform each of the following and verify a corresponding log entry exists with user identifier, source IP, timestamp, and outcome:

A good audit log entry for a failed login looks like this:

{
  "timestamp": "2026-06-19T09:14:32.441Z",
  "event": "auth.login.failed",
  "username": "alice@example.com",
  "source_ip": "185.220.101.47",
  "user_agent": "Mozilla/5.0 ...",
  "reason": "invalid_password",
  "request_id": "req_8fXk2mNpQ"
}

A bad one looks like this:

2026-06-19 09:14:32 - Login failed

The second entry is logged. It is useless for forensics. Both are A09 findings — one is a missing log, the other is insufficient log detail.

Access control event logging

Deliberately trigger access denied conditions and verify they're captured:

These are exactly the events an attacker generates during reconnaissance. If they're not logged, the attacker's probing goes unrecorded.

Critical action audit trails

For each of the following, verify a log entry exists that captures who performed the action, when, from where, and what the outcome was:

Log Injection Testing

Log injection exploits the fact that logs are often plain text files or structured text formats (syslog, JSON) that embed user-supplied values. If those values contain newline characters or format-breaking sequences, an attacker can write arbitrary content into the log stream.

Newline injection

Inject %0a (URL-encoded newline) or %0d%0a (CRLF) into any user-controlled input that the application is likely to log: usernames, email fields in login forms, search queries, API parameters, HTTP headers like User-Agent and X-Forwarded-For.

# Username field injection — inject a fake successful login entry after the real failed one
POST /login
Content-Type: application/x-www-form-urlencoded

username=alice%40example.com%0a2026-06-19+09:15:00+-+Login+successful+for+admin%40example.com&password=wrong

# X-Forwarded-For injection — forge source IP in log entry
X-Forwarded-For: 127.0.0.1%0aINFO: Admin action approved by system

# User-Agent injection — break log format
User-Agent: Mozilla/5.0%0a[CRITICAL] Database backup completed successfully

After submitting these payloads, check the application's log output. If you control the log viewer (grey-box test), look for the injected entries appearing as separate lines. If the injected entries appear as real log events, the application is vulnerable.

ANSI escape code injection

When logs are viewed in a terminal, ANSI escape sequences can hide content, change colors, or overwrite previous lines — useful for obscuring attack activity from engineers reviewing logs manually.

# Clear current line and overwrite with benign content
username=\x1b[2K\x1b[1A\x1b[2KLogin+successful+for+admin

# Hide injected content using color resets
\x1b[0m\x1b[1;32m[INFO]\x1b[0m Normal operation confirmed

JSON log injection

Applications using structured JSON logging are vulnerable to JSON injection if user input is concatenated into log strings rather than serialized properly:

# If the application builds log entries like:
# {"event":"login.failed","user":"USERINPUT"}
# Inject:
username=alice","event":"login.success","user":"admin

# Results in a malformed or attacker-controlled JSON entry:
{"event":"login.failed","user":"alice","event":"login.success","user":"admin"}

Proper mitigation is to use a structured logging library that serializes values as typed fields — never string concatenation into a log template.

Testing for Sensitive Data in Logs

Sensitive data ends up in logs through several common paths: verbose error handlers that dump full request objects, debug logging left enabled in production, and logging middleware that records request/response bodies without filtering.

Trigger error conditions with your own credentials

Submit intentionally malformed requests that cause server errors, using test credentials you control. Then check whether those credentials appear in the log output. Common patterns that expose sensitive data:

Check error response bodies for log file paths

Stack traces and verbose error responses sometimes include log file paths or log content. Look for:

Spring Boot Actuator endpoints are a common source of unintentional log exposure. /actuator/logfile will stream the application log to anyone who can reach the endpoint if access controls are misconfigured.

Common sensitive fields to check

What Automated DAST Tools Catch vs. Miss

Logging failures present a fundamental challenge for black-box DAST tools: the vulnerability is defined by the absence of something in a system the scanner cannot observe.

Test DAST detection Why
Log injection (newline, CRLF) Good Predictable payload patterns; response differences or error messages sometimes confirm injection
ANSI escape code injection Moderate Payloads can be sent; confirming impact requires log access
Exposed log endpoints Good Endpoint discovery + response content matching works well
Sensitive data in error responses Moderate Scanner can trigger errors and check responses for credential patterns
Missing authentication event logging Not possible Requires access to the log system to verify events were recorded
Insufficient log detail Not possible Content and completeness of log entries is not observable externally
Missing SIEM / alerting Not possible Alerting infrastructure is invisible to an external scanner
Sensitive data written to log storage Not possible Log storage is not accessible to the scanner

The honest picture: DAST can test for log injection and exposed log endpoints. It cannot assess whether your logging coverage is adequate. That requires access to the log system — either directly (grey-box testing) or through a log audit process.

How Ironimo Approaches Logging Gap Detection

A09 testing in Ironimo focuses on the subset of logging failures that are externally observable or injectable:

Log injection via all input vectors. Every user-controlled input field — form parameters, URL parameters, HTTP headers (User-Agent, Referer, X-Forwarded-For, custom headers), JSON body fields — is tested with newline injection, CRLF injection, and ANSI escape sequences. Response behavior and error messages are analyzed for confirmation signals.

Exposed log endpoints. Ironimo's scanner probes for common log exposure endpoints: Spring Actuator's /actuator/logfile and /actuator/heapdump, Laravel's /storage/logs/laravel.log, debug endpoints that return log tails, and path traversal against known log file locations.

Error handling analysis. Deliberate error conditions are triggered across all endpoints. Responses are checked for stack traces, log file paths, framework debug output, and credential patterns in error bodies — all of which indicate that sensitive runtime data is leaking outward.

Sensitive data in responses. Ironimo checks whether error responses inadvertently expose log content containing credential patterns, token values, or PII that originated from a log pipeline and made its way back into an API response.

What Ironimo cannot do from the outside: verify that your SIEM has alerting rules configured, confirm that failed authentication events are being written to persistent storage, or audit the completeness of your audit trail fields. That side of A09 requires a log architecture review.

DAST + Log Review: The Complete Coverage Model

A complete A09 assessment combines two complementary activities:

Automated DAST scanning covers the externally testable surface: log injection, exposed endpoints, sensitive data in error responses. Run this continuously — log injection vulnerabilities get introduced when developers add new input fields without sanitization, and they don't show up in code review reliably.

Periodic log architecture review covers the coverage and quality questions: are the right events being logged? Do log entries contain the fields needed for forensics? Are logs being shipped to a SIEM? Are alerting rules configured for the events that matter — brute force, privilege escalation, anomalous export volumes?

Neither is a substitute for the other. An application with zero log injection vulnerabilities but no authentication event logging is still profoundly exposed. An application with detailed, comprehensive logs that are injectable is both over-logging and under-protected.

The practical checklist for a log architecture review:

Key Takeaways

OWASP A09 is the category that enables every other attack to succeed silently. An attacker exploiting A01 (broken access control) or A03 (injection) leaves traces — if you're logging. Without adequate logging, a months-long compromise can remain invisible until the attacker chooses to make it known.

The actionable priorities:

Ironimo tests for log injection vulnerabilities and exposed log endpoints across your entire application — probing every user-controlled input vector with newline, CRLF, and ANSI injection payloads, and scanning for log exposure through debug endpoints and path traversal.

On-demand or scheduled scans using the same Kali Linux toolset professional pentesters run. Every finding includes the exact request, the confirming response, and a remediation path.

Start free scan

Related reading

← Back to blog