Insufficient Logging & Monitoring
debt(d7/e5/b5/t7)
Closest to 'only careful code review or runtime testing' (d7). The detection_hints note `automated: no` and while tools like semgrep, splunk, and datadog are listed, they require manual configuration of rules and baselines — they don't catch missing logging out of the box. Absence of logging is structural and requires deliberate audit of code paths rather than a single tool scan.
Closest to 'touches multiple files / significant refactor in one component' (e5). The quick_fix identifies specific event categories to log (auth, access control, validation failures), but adding structured, contextual logging across authentication flows, access control checks, and input validation paths in a web/API codebase touches many files and requires consistent patterns. It's more than a one-line fix but not a full architectural rework.
Closest to 'persistent productivity tax' (b5). Applies to web and API contexts broadly. Insufficient logging creates an ongoing operational burden — every incident investigation is harder, alert rules cannot be written, and dashboards are impossible. It slows down security and ops work streams continuously but doesn't reshape every feature's development the way a foundational architectural choice would.
Closest to 'serious trap' (t7). The misconception field captures it precisely: developers believe logging only matters after a breach, when in fact logs are the primary real-time detection mechanism. This contradicts the intuition that logging is a post-hoc forensic tool, and the common mistakes show multiple independent ways to get it wrong (wrong level, missing context, unstructured, logging sensitive data) — each feeling 'good enough' while silently failing.
Also Known As
TL;DR
Explanation
Without adequate logging of authentication attempts, access control failures, input validation errors, and administrative actions, attackers can operate undetected for extended periods — the industry average time to detect a breach is over 200 days. Effective security logging must be tamper-resistant, centralised, include timestamps and user context, and be actively monitored with alerts for anomalous patterns. In PHP, use a structured logging library such as Monolog and ship logs to a separate SIEM rather than writing to local files.
Common Misconception
Why It Matters
Common Mistakes
- Logging everything at DEBUG level in production — log volume makes finding signal impossible and inflates costs.
- Not including context (user ID, request ID, correlation ID) — a log line without context cannot be traced to a cause.
- Using string concatenation instead of structured logging — machine-readable logs enable alerting and dashboards.
- Logging sensitive data (passwords, tokens, PII) — logs are often stored less securely than databases.
Code Examples
// Silent failure — no trace of what happened
public function login(string \$email, string \$password): ?User {
\$user = User::where('email', \$email)->first();
if (!\$user || !password_verify(\$password, \$user->password)) {
return null; // attacker can try forever undetected
}
return \$user;
}public function login(string \$email, string \$password): ?User {
\$user = User::where('email', \$email)->first();
if (!\$user || !password_verify(\$password, \$user->password)) {
\$this->logger->warning('Failed login attempt', [
'email' => \$email,
'ip' => request()->ip(),
'ua' => request()->userAgent(),
]);
return null;
}
\$this->logger->info('User logged in', ['user_id' => \$user->id, 'ip' => request()->ip()]);
return \$user;
}