> ## Documentation Index
> Fetch the complete documentation index at: https://notes.kodekloud.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Logging and Monitoring Audit
> Guide to auditing and improving application logging and monitoring, preventing secret exposure, enabling security telemetry, structured logs, rotation, alerts, and providing remediation examples for Node.js and Express
This lesson walks through auditing an application's logging and monitoring implementation to ensure it:
* Does not expose secrets (passwords, tokens, connection strings, PII).
* Produces the security telemetry needed (failed logins, authorization failures, validation failures, system errors).
* Provides meaningful alerts and supports incident response.
This guide focuses on practical audit steps, evidence to collect, and precise remediation examples you can apply immediately. Use the remediation snippets as drop-in patterns for Node.js/Express apps, and adapt them to other stacks as needed.
Why this matters
* Missing or insufficient logging and monitoring is a security weakness: attacks, misconfigurations, or data exposures can go unnoticed.
* Over-verbose or unsanitized logs can leak secrets (passwords, tokens, connection strings), PII, or SQL statements.
* Lack of structured logs, rotation, and retention policies creates reliability, compliance, and incident-response problems.
Audit goals (what we check)
1. Sensitive data is not logged (passwords, tokens, PII, credit card numbers, API keys).
2. Security event logging coverage exists (failed login attempts, authorization failures, validation failures, system errors).
3. Log injection prevention (input sanitization, structured logging).
4. Log storage and retention (secure storage, rotation policy, backups).
5. Monitoring and alerts (unusual-activity detection, error-rate monitoring, performance anomalies).
Required deliverable for each finding
* Title, Severity (Critical/High/Medium/Low), CWE (if applicable)
* Evidence (file, function, line ranges, reproduction artifacts)
* Why it matters
* Exploitability notes and a safe minimal PoC / reproduction steps (do not include real secrets)
* Remediation: precise code-level fix or config change (snippets welcome)
* Summary risk score (0–10) and top prioritized fixes
Common problems discovered (summary)
* Direct console dumps of full error objects (`console.error`, `console.log`), which may include secrets.
* No structured logging framework; logs are plain text and hard to parse/aggregate.
* Missing security event logs for failed authentication, authorization, and validation events.
* Unsanitized user inputs included directly in logs (log injection risk).
* No log rotation/retention policy (disk fill, lost evidence).
* No monitoring endpoints or metrics exported (no alerts for spikes, slow responses, or brute-force activity).
Findings and remediation examples
1. Sensitive Data Exposure in Error Logs
* Problematic pattern:
```javascript theme={null}
// routes/auth.js (problematic)
console.error('Login error:', error);
```
* Why it matters: Full error objects can contain stack traces, DB connection strings, user data, and other secrets. Logging them aids attackers and causes information disclosure.
* Remediation: Sanitize and limit error fields before logging. Only include the minimal fields required for triage.
```javascript theme={null}
// helpers/logging.js
function sanitizeError(err) {
return {
message: err && err.message ? err.message : 'Unknown error',
code: err && err.code ? err.code : undefined,
// include stack only in non-production or redact sensitive paths
stack: process.env.NODE_ENV === 'production' ? undefined : err && err.stack
};
}
module.exports = { sanitizeError };
```
```javascript theme={null}
// routes/auth.js (fixed)
const { sanitizeError } = require('../helpers/logging');
const errorInfo = sanitizeError(error);
logger.error('Login error', errorInfo);
```
Avoid logging raw error objects in production. If you must include a stack trace, ensure it is only enabled in non-production environments and never contains environment variables or connection strings.
2. Replace console.\* with a structured logger (Winston / Pino)
* Problem: Ad-hoc console logging makes searching, retention, and alerting difficult.
* Minimal Winston example (structured JSON logs with rotation):
```javascript theme={null}
// logger.js
const { createLogger, format, transports } = require('winston');
require('winston-daily-rotate-file');
const jsonFormat = format.combine(
format.timestamp(),
format.json()
);
const transport = new transports.DailyRotateFile({
filename: 'logs/application-%DATE%.log',
datePattern: 'YYYY-MM-DD',
maxSize: '20m',
maxFiles: '14d'
});
const logger = createLogger({
level: process.env.LOG_LEVEL || 'info',
format: jsonFormat,
transports: [
transport,
new transports.Console({ format: format.combine(format.colorize(), format.simple()) })
]
});
module.exports = logger;
```
* Use the logger consistently and avoid logging secrets:
```javascript theme={null}
const logger = require('./logger');
logger.info('User login success', { userId: user.id, ip: req.ip }); // avoid logging email/password
logger.warn('Failed login attempt', { email: obscure(email), ip: req.ip });
logger.error('Database connection error', sanitizeError(err));
```
3. Prevent log injection and ensure fields are sanitized
* Problem: User-controlled strings (userAgent, email, username) are logged directly and may contain newlines or control characters that enable log forging/injection.
* Remediation: Escape newline/control characters, trim length, and obscure sensitive parts.
```javascript theme={null}
// helpers/sanitize.js
function sanitizeForLog(input, maxLen = 512) {
if (!input) return input;
return String(input)
.replace(/[\r\n]+/g, ' ') // remove newlines to prevent log forging
.replace(/\t/g, ' ')
.slice(0, maxLen);
}
function obscure(value) {
if (!value) return value;
return value.slice(0, 3) + '***';
}
module.exports = { sanitizeForLog, obscure };
```
Usage:
```javascript theme={null}
const { sanitizeForLog, obscure } = require('../helpers/sanitize');
logger.warn('Failed login attempt', {
email: obscure(sanitizeForLog(email)),
ip: req.ip,
userAgent: sanitizeForLog(req.get('User-Agent'))
});
```
4. Security event logging coverage
Ensure you log, at minimum:
* Failed and successful login attempts (non-sensitive metadata: userId, partial email, IP, timestamp).
* Authorization failures (resource, userId, roles checked).
* Input validation failures (field names, violated validation rules, IP).
* System errors (sanitized error message, component, request id).
Example structured auth success log:
```javascript theme={null}
logger.info('Authentication:login_success', {
userId: user.id,
ip: req.ip,
sessionId: req.sessionID
});
```
5. Health checks, metrics, and monitoring endpoints
* Add a simple health endpoint for uptime probes:
```javascript theme={null}
// app.js
app.get('/health', (req, res) => {
res.json({ status: 'ok', timestamp: new Date().toISOString() });
});
```
* Export metrics (error counts, request durations) via Prometheus client or equivalent to detect anomalies and trigger alerts.
6. Log rotation, retention, and secure storage
* Use rotating file transports (example above uses winston-daily-rotate-file).
* Configure retention and encryption at rest according to policy.
* Forward logs to a centralized log store (ELK, Datadog, Sentry, Splunk) using TLS and RBAC controls.
7. Monitor for unusual activity and add alerts
* Example alerting rules:
* Failed logins per minute per IP > threshold → alert.
* Error rate spike (5xx responses) > threshold over 5 minutes → alert.
* Sudden traffic anomaly (geo or volume) → alert.
* Integrate with a SIEM for event correlation and to reduce false positives.
Compliance checklist (high-level)
| Requirement | Status | Evidence / Notes |
| - | -: | - |
| Sensitive data not logged | ❌ FAIL | Full error objects logged with `console.error` in places. |
| Security event logging | ❌ FAIL | Missing consistent failed/success auth logs and authorization failure logs. |
| Log injection prevention | ❌ FAIL | Inputs logged without sanitization. |
| Structured logging | ❌ FAIL | Mostly ad-hoc console logs; no centralized logger. |
| Log rotation & retention | ❌ FAIL | No rotation/retention policies or transports configured. |
| Monitoring & alerts | ❌ FAIL | No metrics endpoint or alerting configured. |
Top 5 prioritized fixes (implement in order)
1. Sanitize and limit what you log; replace `console.*` dumps with sanitized structured logging (Critical).
2. Add failed authentication and success logs to detect brute-force or account enumeration (High).
3. Implement structured logging (Winston/Pino) and forward logs to a centralized store (High).
4. Sanitize user inputs before logging to prevent log injection (Medium).
5. Configure log rotation/retention and add basic monitoring endpoints + metrics export (Medium).
Sample risk assessment summary
* Overall risk score: 7.0/10 — immediate action recommended to avoid information disclosure and enable detection of incidents.
* Most urgent: remove full object dumps from logs and centralize logging so you can monitor failed authentication and error spikes.
Defense-in-depth recommendations
1. Use a structured logging library and central aggregator (ELK, Datadog, Splunk).
2. Implement metrics collection (Prometheus) and dashboards (Grafana) for performance and error monitoring.
3. Integrate security events into a SIEM for correlation and alerting.
4. Encrypt logs at rest and in transit and enforce RBAC for access.
5. Schedule regular log audits and retention policy reviews.
Small checklist to get started (concrete actions)
* Replace direct `console.error('...', error)` with sanitized logger calls.
* Add `logger.warn`/`logger.info` for failed/successful auth events with non-sensitive metadata.
* Add a health endpoint and basic Prometheus metrics.
* Configure daily rotating logs with retention (example: 14 days).
* Centralize logs and set alert rules for failed login spikes and error-rate anomalies.
Conclusion
The audit finds the application lacks production-grade logging and monitoring controls. Implementing structured logging, input sanitization, event coverage for auth/validation failures, rotation/retention, and basic monitoring/alerting will reduce information-disclosure risk and improve detection and response to incidents.
Next steps (recommended focused patch set)
* Replace console usage with the logger in auth and DB modules.
* Add sanitize helpers and update log calls across the codebase.
* Add rotating transport and a simple health/metrics endpoint, then forward logs to a centralized store.
Links and references
* [Winston logger](https://github.com/winstonjs/winston)
* [Pino logger](https://github.com/pinojs/pino)
* [Prometheus](https://prometheus.io)
* [ELK Stack](https://www.elastic.co/what-is/elk-stack)
* [Datadog](https://www.datadoghq.com)
* [Sentry](https://sentry.io)
* [Splunk](https://www.splunk.com)
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.