[Bug]: Sensitive data leaking into logs (auth code, signatureSecret, clientInput)

[taheerahmed]

Summary

Three related logging issues that expose sensitive data in application logs.

---

1. Full auth code logged on error in callback route

File: src/app/api/auth/callback/route.ts (line 42)

When exchangeCodeForSession fails, the full authorization code is included in the error log context:

context: {
    code,       // full auth code in error log
    origin,
    returnTo,
    redirectTo,
},

While the code is likely consumed at this point, full credentials should not appear in logs.

Fix: Log code?.slice(0, 8) or !!code instead of the full value.

---

2. Logger redaction config missing key patterns

File: src/lib/clients/logger/logger.ts (lines 54-76)

The pino redaction config does not cover:

• signatureSecret / *.signatureSecret — used in webhook actions, does not match the existing *.secret pattern (pino matches exact path segments)
• access_token / *.access_token — the actual Supabase session field name uses underscore, but only accessToken (camelCase) is covered

Fix: Add signatureSecret, *.signatureSecret, *.*.signatureSecret, access_token, *.access_token, *.*.access_token to REDACTION_PATHS.

---

3. Full clientInput logged for every server action

File: src/lib/clients/action.ts (line 80)

The base action client middleware logs server_function_input: clientInput for every action call. While pino redaction covers keys like password and secret, fields like signatureSecret in webhook actions bypass the redaction patterns. Any new action with non-standard sensitive field names would also be logged in cleartext.

Fix: Either (a) stop logging raw clientInput and log only specific non-sensitive fields needed for debugging, or (b) ensure all sensitive field names are covered by redaction paths (see issue 2 above).

---

Impact

If logs are stored in a centralized logging system (Loki, as configured in the codebase), anyone with log access could see auth codes, webhook signing secrets, and other sensitive action inputs.

Environment

Identified via code review of src/lib/clients/logger/logger.ts, src/lib/clients/action.ts, and src/app/api/auth/callback/route.ts.

[linear]

ENG-3553

[taheerahmed]

@ben-fornefeld if this is an actual issue that needs to be taken care of please let me know I would like to get this fixed too..

[xXMrNidaXx]

Additional Considerations for the Fix

Great security review! A few additional patterns worth considering:

1. Deep path redaction for nested objects

Pino redaction uses glob patterns, but nested structures in action inputs may need wildcards:

const REDACTION_PATHS = [
  // Exact matches
  'password', 'secret', 'signatureSecret', 'access_token', 'accessToken',
  // Single level nesting
  '*.password', '*.secret', '*.signatureSecret', '*.access_token',
  // Two levels deep (covers action.input.secretField)
  '*.*.password', '*.*.secret', '*.*.signatureSecret', '*.*.access_token',
  // Auth code patterns
  'code', '*.code', 'authCode', '*.authCode',
]

2. Consider an allowlist instead of blocklist

For clientInput logging, a safer pattern is logging only known-safe fields:

const SAFE_TO_LOG = new Set(['action', 'timestamp', 'userId', 'sandboxId'])

function sanitizeInput(input: Record<string, unknown>) {
  return Object.fromEntries(
    Object.entries(input)
      .filter(([key]) => SAFE_TO_LOG.has(key))
  )
}

This defaults to not logging new fields rather than hoping redaction catches everything.

3. Auth code handling

Even partially logged auth codes (like code?.slice(0, 8)) could be risky in some contexts. Consider just logging existence:

context: {
  hasCode: Boolean(code),
  origin,
  // ...
}

4. Webhook signature audit

Given signatureSecret was missed, worth auditing all webhook-related code for similar patterns — any field ending in Secret, Key, Token, or Credential should be caught.

[taheerahmed]

Great stuff ! I think I would just go ahead and do this !

[taheerahmed]

Opened a PR with the fix: #260