What it is
This category is about visibility. If someone tries ten thousand passwords, is that recorded anywhere? If an admin action happens at 3am, does anyone find out? If a breach starts, how many days until you notice? Failures here do not cause the breach; they turn a contained incident into a long one. The 2025 rename from monitoring to alerting makes the point: logs nobody reads are not a control.
It also covers the opposite failure: logging too much. Passwords, tokens, card numbers and personal data written to a log file are a breach waiting for anyone with read access to that file.
How it shows up in AI-generated code
AI-built apps tend to sit at one of two extremes. Either there is no logging beyond the framework default, because nothing in the prompt asked for it, or there is a console.log of the whole request object on every handler, left over from debugging, which puts every Authorization header and request body into the host's log stream. Prbl flags the second pattern as sensitive data in logs.
What is almost never present: a log line for a failed login, a log line for a permission denial, or any alert wired to either. Those three lines are the difference between noticing a credential-stuffing attack in an hour and noticing it in a quarter.
Example: Logging the whole request
app.post("/api/login", async (req, res) => {
console.log("login", req.body, req.headers); // password + tokens in logs
...
});app.post("/api/login", async (req, res) => {
const ok = await checkPassword(req.body.email, req.body.password);
log.info({ event: "login", email: req.body.email, ok, ip: req.ip }); // no secret
if (!ok) failedLogins.inc({ email: req.body.email }); // alert on spikes
...
});Log the event and its outcome, never the credential. Count failures per account and per IP, and put an alert on the count.
How to find it
- Search for console.log, print and logger calls that include req.body, req.headers, a token, a password, or a whole user object.
- Try a failed login and check whether anything was recorded.
- Ask: if a key leaked right now, what would tell me? If the answer is nothing, that is the finding.
- Check where logs go and who can read them. A public log endpoint or a world-readable file is a data leak.
- Prbl rule for sensitive data in logs covers the over-logging case; the guide below is the checklist for the rest.
How to fix it
- Log authentication events, authorization denials, and admin actions, with who, what, when and from where.
- Never log credentials, tokens, session IDs, card numbers or full request bodies. Redact by default.
- Send logs somewhere durable that the app server cannot delete.
- Wire one alert: failed logins per account or per IP above a threshold. Add more later.
- Keep enough history to reconstruct an incident, typically ninety days.
What Prbl checks for this category
Run a free scan on a public repo or a live URL. Findings link to the fix guides below.
Fix guides for this category
Go deeper
Common questions
What is the minimum I should log?
Three things: every login attempt with its outcome, every authorization denial, and every admin or money-moving action. With who, when and from which IP, and never with the credential. That is enough to detect the common attacks and reconstruct most incidents.
Is console.log in production a security issue?
It is if it logs request bodies, headers, or user objects, which debugging code usually does. Those lines end up in your host's log viewer, in third-party log tools, and in support tickets. Replace them with structured logs that name the fields they include.
Why did OWASP change monitoring to alerting?
To make the point that collecting logs is not the control. The control is someone or something reacting. A dashboard nobody watches is monitoring; a page when failed logins spike is alerting.