This lesson's interactive features are locked, please to keep using them

Observability

If you're learning about an attack from your own users (or worse, TechCrunch), you've done something horribly wrong.

Many attacks start with indicators: more failures than normal, odd timings, repeated requests that don't quite look human. Good logs and metrics are how you notice those patterns before too much damage is done.

Logs and Metrics

Logs answer what exactly happened – which user, which IP, which endpoint, what outcome. They're queryable records you can search during an investigation.
Metrics answer how often something is happening and whether it's normal. They're aggregated counts and rates that you can graph and alert on.

A useful security log entry includes enough context to reconstruct what happened without exposing sensitive data. It should include things like:

timestamp
endpoint or action
outcome
user ID (not email)
source IP
request ID

It should exclude or redact:

passwords
tokens
full request bodies
any other PII you don't need for the investigation

Good logs and metrics aren't just about uptime and performance. They're a preventive security feature!

Suspicious Patterns

A single failed login is no big deal, but 3,821 failed logins from the same IP in a single minute are likely a sign of a brute-force attack:

2024-05-10T09:12:01Z login_attempt outcome=failure userId=null ip=203.0.113.10
2024-05-10T09:12:03Z login_attempt outcome=failure userId=null ip=203.0.113.10
2024-05-10T09:12:05Z login_attempt outcome=failure userId=null ip=203.0.113.10
2024-05-10T09:12:07Z login_attempt outcome=failure userId=null ip=203.0.113.10

Assignment

Bearly Secure's authentication logs cannot reliably connect an event to the request that caused it. The routes already use a logAuthenticationEvent wrapper in src/routes/auth.ts, but it's a pass-through that adds nothing to the log entry.

Add correlated structured logging to the login and password reset flows.

Add custom middleware that sets an "X-Request-ID" header with a random UUID. Also, store the request ID in the response's .locals object under the requestId key so downstream handlers can log it. Register the middleware in src/app.ts before every other middleware so every response gets an ID.
In src/routes/auth.ts, update logAuthenticationEvent so that, in addition to the fields it's given, every event records:
- requestId: the ID from res.locals.requestId
- sourceIp: use the provided clientIpKey helper from "../security/rateLimit.ts"
- userId: the user's ID, or null when the request never identified a user (so the key is always present)
- outcome: "success" or "failure", based on the event's success field
Start the app.

With Bearly Secure still running, run and submit the CLI tests from the project root.