Logging and audit trails you can trust

Why this area matters

Security logging and monitoring failures are OWASP Top 10 A09. Breaches often go unnoticed for months because sensitive actions were never logged, or the logs that existed couldn't be trusted. At the same time, logs regularly become a leak themselves: tokens, passwords and personal data written to them end up in log aggregators with far wider access than the original system (CWE-532, CWE-117, CWE-778).

Scanners flag individual log calls but can't tell whether an audit trail exists for a sensitive action, or whether a logged value is a secret. The review step reads the handler as a whole.

What goes wrong in real applications

• Secrets and personal data in logs

  Logging authorization headers, tokens or full request bodies copies credentials into every system that stores or ships logs.

• Log injection

  Writing unescaped user input into plain-text logs lets it forge entries that look like real events, misleading investigators.

• Missing audit events

  Role changes, permission grants, exports and login failures that aren't recorded leave no trail to reconstruct what happened.

• Tamperable logs

  Logs the application can rewrite or delete — local files with no shipping, shared credentials for the log store — can't be relied on after a compromise.

Sample: the risky pattern and the fix

@app.post("/admin/users/<uid>/role")
@require_admin
def set_role(uid):
    log.info("admin call auth=%s", request.headers.get("Authorization"))
    log.info("role change note: " + request.json["note"])
    db.users.update_one({"_id": uid}, {"$set": {"role": request.json["role"]}})
    return "", 204

@app.post("/admin/users/<uid>/role")
@require_admin
def set_role(uid):
    body = RoleChange.model_validate(request.json)
    db.users.update_one({"_id": uid}, {"$set": {"role": body.role}})
    audit.record(                      # structured, append-only audit sink
        actor=current_user.id, action="user.role_change",
        target=uid, new_role=body.role, note=body.note,
        ip=request.remote_addr,
    )
    return "", 204

The original writes the caller's bearer token into the logs, concatenates free text that can forge log lines, and never records who changed whose role. The fix drops the token, validates input, and emits a structured audit event to an append-only sink, so the trail is both complete and safe to share.

Illustrative code, simplified for clarity — not taken from a customer repository.

What OpenRouting checks in your repository

• Log calls that include tokens, authorization headers, passwords or full request bodies (routed to the secrets agent)
• Unstructured logging of raw user input
• Sensitive actions — role changes, exports, deletions, auth failures — with no audit record
• Logging configuration in the repo: local-only files, disabled shipping, debug-level logging in production

Scope and limits

• It reviews logging code and config; it doesn't collect, search or analyze your runtime logs, and it doesn't perform incident forensics.
• Retention, immutability and access controls in your log platform live outside the repository. For an active incident, a manual expert review can be requested from the dashboard.

Coverage areas reflect OpenRouting's check library. Code, secret and infrastructure scanning run today; other areas are rolling out. Scanners surface candidates and a review agent decides whether each one is real — it doesn't promise to find every issue.

Review agents for this area

• Secrets & data exposure — Judges whether a flagged value is really a secret and whether sensitive data leaks through logs or errors.
• Blast radius & data exposure — Assesses how much damage a compromise of this code could cause, and how to shrink it.